TaskFlow, by the end of the previous lesson, is already a complete and functional application: five assembled components, a shared context, a reactive controller, a mixin, and a simulated service, all coordinated exactly as planned in the first lesson of this module. Before the project can truly be called finished, what remains is to check with automated tests the pieces completed in this module that module 9 couldn't cover because they didn't exist yet, to bundle the application for deployment, and to decide whether any of its pieces deserve to be published separately as a reusable library. This is the last lesson of the course: it introduces no new Lit concepts, and closes, in its final section, the complete journey started in the lesson "What are Web Components and Why Lit?".

1. What's left to close before finishing
2. Final testing checklist: what 09-01 and 09-02 didn't get to cover
3. New tests: <task-filter> and the complete flow of an event
4. Final build with Vite: commands and the structure of dist/
5. Publishing <task-card> as a reusable npm library
6. Deployment checklist: static site vs. library
7. TaskFlow, from start to finish: a module-by-module review
8. Next steps, beyond this course
9. Closing the course

Module 9 built TaskFlow's test suite (09-01), its accessibility (09-02), its performance (09-03), and its catalog of patterns and anti-patterns (09-04) on top of the application as it existed then: without a well-established <task-filter>, with <task-board> still on an earlier version of its initial load. This module has completed those pieces, and this lesson closes the circle: it extends the test suite to what was missing, gets the application ready to be published, and with that brings the entire course to a close.

Before writing any new test, it's worth taking an honest inventory of which part of TaskFlow already has coverage and which doesn't, using exactly the same tools from the lesson "Unit Testing with Web Test Runner" (09-01):

The first two rows were already resolved; the last three are exactly the pieces this module has added or completed, and they're the ones covered in the next section.

The first new test checks <task-filter> in isolation, but to truly exercise its behavior it needs to be wrapped in a test context provider, since <task-filter> on its own, without any ancestor publishing filtroContext, would only see the fallback value defined in its own valorActual:

The second test checks the complete flow from section 2, third row: that a state change triggered inside the shadow root of a <task-card>, several levels below, ends up actually modifying <task-board>'s tareas array, exactly the path described in the map from lesson 10-01.

aTimeout, also imported from @open-wc/testing, is a small utility that returns a promise that resolves after the given number of milliseconds; it's used here because the simulated load from tareas-service.js (lesson 07-03, consolidated in 10-03) takes real time, not artificial, and the test needs to wait that same amount of time before any <task-card> exists to act on. The rest of the test chains three different updateComplete calls —for the card, the list, and the board— because, as explained in the lesson "Parent-to-Child Communication with Properties" (05-03) and in "Communication Patterns between Sibling Components" (05-04), the event crosses two forwardings before reaching <task-board>, and each level needs to complete its own update before the next one reflects it.

With the tests now complete, TaskFlow's production build as an application follows exactly the criteria set in the lesson "Bundling, Publishing, and TypeScript" (08-04, sections 1 and 4): Vite, not Rollup directly, because TaskFlow is a self-sufficient application, not a library meant for another bundler to reprocess.

The result, in dist/, looks like this:

Each file name includes a hash fragment derived from its content (a1b2c3d4, in the example), exactly the cache-control mechanism explained in 08-04: if a file's content doesn't change between two successive deployments, its name doesn't change either, and the browser of someone who already visited TaskFlow can keep using the copy it already has cached without downloading it again. index.html, regenerated by Vite on every build, already points to the correct file names for that specific build, with no need to manually edit any path.

TaskFlow, as a complete application, is deployed with the build from the previous section. But a different question fits here, already raised in the abstract in lesson 08-04: is it worth publishing <task-card> separately, so other projects —not just TaskFlow— can install it as an npm dependency? If the answer were yes (reasonable, given that <task-card> doesn't depend on any TaskFlow-specific data except what it receives as properties), the package.json of that standalone package would need to declare lit as an external dependency, not bundled in, for exactly the reason explained in 08-04 (section 3): avoiding two third-party components, both dependent on Lit, loading two full copies of the library in the same application.

peerDependencies is the piece that formalizes that decision: it declares that the package expects whoever installs it to provide their own copy of lit, rather than bundling its own. devDependencies keeps a copy of lit available only during the package's own development (to run its tests or its build), without that copy traveling inside the final published package. The Rollup configuration, identical to the one in lesson 08-04, produces the dist/task-card.js that this package.json references:

external: ['lit', /^lit\//] is the detail that was missing from the example in lesson 08-04: it tells Rollup not to include, in the final bundle, either the lit package itself or any of its submodules (lit/directives/..., lit/decorators.js), leaving those imports intact in the output so that the bundler of whoever installs @taskflow/task-card resolves them with their own copy of Lit, consistent with the peerDependencies declaration in the package.json.

Both paths are legitimate and not mutually exclusive: nothing prevents TaskFlow from being deployed as a complete application (section 4) while, in parallel, <task-card> is also published as a standalone package (section 5) for other teams to reuse outside of TaskFlow, exactly the same component in both cases, just bundled in two different ways depending on who each result is aimed at.

With TaskFlow now tested, bundled, and ready to be deployed, it's worth looking back and covering, at a glance, the whole path of this course:

No row in this table is a surprise at this point in the course; it's included here, in the last lesson, precisely so the whole journey can be seen in one go, something no earlier lesson, focused on its own module, could offer.

This course has covered Lit exhaustively for the kind of application TaskFlow represents, but the ecosystem around Lit keeps growing, and it's worth pointing out a few concrete paths for anyone who wants to continue beyond this final lesson:

• @lit-labs/virtualizer: the lesson "Performance and Optimization" (09-03, section 9) mentioned virtualization as a technique for lists of tens of thousands of elements, beyond the practical scope of this course, and noted that TaskFlow didn't need it. It's, literally, the natural next step if <task-list> had to grow well beyond the data volumes handled in module 9.
• @lit-labs/motion: an experimental package from Lit's own ecosystem for declarative animations between states, an area this lesson has only touched manually with the CSS animation of resaltarSiUrgente (lesson 10-02).
• @lit-labs/observers: reactive controllers already written by the Lit team to wrap ResizeObserver, IntersectionObserver, and other browser observation APIs, following exactly the same ReactiveController pattern studied in lesson 06-03 with ContadorTiempoRestanteController.
• Exploring Lit with TypeScript and decorators in more depth: lesson 08-04 presented the syntactic equivalence between static properties and decorators; progressively migrating TaskFlow, component by component, is a natural hands-on exercise to consolidate that lesson with a real project.
• The official documentation at lit.dev: in particular its recipes section (Playground) and its release notes, to keep a close eye on any future API changes as Lit evolves beyond the version studied in this course.

This course began, in the lesson "What are Web Components and Why Lit?", with a question about web platform standards and a promise: to learn how to build reactive interfaces with the browser's own components, without depending on a full application framework. Ten modules and thirty-nine lessons later, that promise has been fulfilled with a real, complete application, TaskFlow, built piece by piece, module by module, without leaving any loose ends: every concept presented was immediately applied to the project itself, and every piece mentioned without being fully resolved —from <task-filter> in module 5 to the resaltarSiUrgente animation in this final lesson— found its place before the course ended.

Anyone who has followed the whole course, writing and testing every example, already has the judgment needed to tackle a real project with Lit: when to lift state to a common ancestor and when to reach for a shared context; when a reactive controller and when a mixin; when until and when an explicit loading property; and, above all, the habit of asking, faced with every design decision, which of the two alternatives better avoids the anti-patterns cataloged in module 9. That judgment, more than memorizing a specific API, is what survives once a course is over.

Congratulations on making it this far. TaskFlow is finished, tested, and ready to be deployed; the rest of the road, with Lit or with any other tool, is now in your hands.

• Publishing a library without declaring lit as an external dependency: as explained in section 5, and already warned about in lesson 08-04, forgetting external in the Rollup configuration would include a full copy of Lit inside the published package, with the already-known duplication risk.
• Running vite build expecting the same result as for a library: as the table in section 6 reminds us, each deployment path has a different tool and configuration; mixing both goals into the same build configuration usually produces a result that doesn't serve either case well.
• Accepting an incomplete test suite just because module 9 already started it: as seen in section 2, <task-filter> and the complete tarea-cambiada flow had no tests until this lesson; before considering any project fully tested, it's worth reviewing which pieces were added after the last time tests were written.
• Treating this lesson as the end of learning, not just of the course: as section 8 points out, the Lit ecosystem stays alive beyond these forty lessons; the judgment learned here is the foundation for continuing to explore, not a final stop.

1. Add a test to test/task-board.test.js that checks that, after changing the search text in <task-filter>'s <input> (accessible from tablero.shadowRoot.querySelector('task-filter').shadowRoot.querySelector('input')), the number of visible <task-card> elements inside <task-list> decreases accordingly. Remember to wait for updateComplete at each level involved, as in the test in section 3.
2. Complete the package.json from section 5 by adding a "build": "rollup -c" script and explain, based on lesson 08-04 (section 2), why this package uses Rollup while the complete TaskFlow application, in section 4 of this lesson, uses Vite for the same verb "to build".
3. Review the table in section 7 and, for the module you think brought the most important change to TaskFlow's overall architecture (not to a specific technique, but to how the components are organized among themselves), justify your choice with a concrete example from the project itself.

2. This package uses Rollup because its goal, as explained in lesson 08-04 (section 1) and recalled in section 6 of this lesson, is to produce a library reusable by other bundlers, not a self-sufficient application ready to be served directly; Rollup produces a clean output close to the source code, designed precisely so an external bundler (that of whoever installs @taskflow/task-card) can reprocess it according to its own needs. The complete TaskFlow application, on the other hand, has no external consumer that will bundle it again: its goal is the final result already optimized for the browser, with chunk splitting and hash-based cache management, which Vite provides out of the box (using Rollup underneath, but with a configuration aimed at applications, not libraries).
3. A reasonable answer points to module 5, with the appearance of <task-board>: before that lesson, <task-list> kept its own array of sample tasks and no component existed capable of coordinating more than two levels of the hierarchy; starting with "Communication Patterns between Sibling Components" (05-04), TaskFlow's whole architecture came to be organized around a common ancestor that distributes properties downward and gathers events upward, the same pattern that, extended with the filter context in module 7, remains in force with no structural changes up to the final version consolidated in this module 10. Other equally valid answers could point to module 7, for introducing @lit/context as an alternative to manually forwarding properties, or module 4, for the appearance of <user-avatar> as the first example of decomposing into a reusable child component.