TaskFlow, al terminar la lección anterior, ya es una aplicación completa y funcional: cinco componentes ensamblados, un contexto compartido, un controlador reactivo, un mixin y un servicio simulado, todos coordinados exactamente como se planeó en la primera lección de este módulo. Falta, antes de poder decir que el proyecto está realmente acabado, comprobar con pruebas automatizadas las piezas que se completaron en este módulo y que el módulo 9 no pudo cubrir por no existir todavía, empaquetar la aplicación para su despliegue, y decidir si alguna de sus piezas merece publicarse por separado como librería reutilizable. Esta es la última lección del curso: no introduce ningún concepto nuevo de Lit, y cierra, en su última sección, el recorrido completo iniciado en la lección "¿Qué son los Web Components y por qué Lit?".

1. Qué queda por cerrar antes de terminar
2. Checklist final de pruebas: lo que 09-01 y 09-02 no llegaron a cubrir
3. Nuevos tests: <task-filter> y el flujo completo de un evento
4. Build final con Vite: comandos y estructura de dist/
5. Publicando <task-card> como librería npm reutilizable
6. Checklist de despliegue: sitio estático frente a librería
7. TaskFlow, de principio a fin: un repaso módulo a módulo
8. Próximos pasos, fuera de este curso
9. Cierre del curso

El módulo 9 construyó la batería de pruebas de TaskFlow (09-01), su accesibilidad (09-02), su rendimiento (09-03) y su catálogo de patrones y anti-patrones (09-04) sobre la aplicación tal como existía entonces: sin <task-filter> bien establecido, con <task-board> todavía en una versión anterior de su carga inicial. Este módulo ha completado esas piezas, y esta lección cierra el círculo: extiende la batería de pruebas a lo que faltaba, deja lista la aplicación para publicarse, y con ello da por terminado el curso completo.

Antes de escribir ningún test nuevo, conviene un inventario honesto de qué parte de TaskFlow ya tiene cobertura y cuál no, usando exactamente las mismas herramientas de la lección "Pruebas Unitarias con Web Test Runner" (09-01):

Las dos primeras filas ya estaban resueltas; las tres últimas son exactamente las piezas que este módulo ha añadido o completado, y son las que se cubren en el apartado siguiente.

El primer test nuevo comprueba <task-filter> de forma aislada, pero para ejercitar de verdad su comportamiento hace falta envolverla en un proveedor de contexto de prueba, ya que <task-filter> por sí sola, sin ningún ancestro que publique filtroContext, solo vería el valor de respaldo definido en su propio valorActual:

El segundo test comprueba el flujo completo del apartado 2, tercera fila: que un cambio de estado disparado dentro del shadow root de una <task-card>, varios niveles por debajo, termina modificando de verdad el array tareas de <task-board>, exactamente el recorrido descrito en el mapa de la lección 10-01.

aTimeout, importada también de @open-wc/testing, es una pequeña utilidad que devuelve una promesa que se resuelve tras el número de milisegundos indicado; se usa aquí porque la carga simulada de tareas-service.js (lección 07-03, consolidada en 10-03) tarda un tiempo real, no artificial, y el test necesita esperar ese mismo tiempo antes de que exista ninguna <task-card> sobre la que actuar. El resto del test encadena tres updateComplete distintos —de la tarjeta, de la lista, del tablero— porque, como se explicó en la lección "Comunicación de Padre a Hijo con Propiedades" (05-03) y en "Patrones de Comunicación entre Componentes Hermanos" (05-04), el evento atraviesa dos reenvíos antes de llegar a <task-board>, y cada nivel necesita completar su propia actualización antes de que el siguiente la refleje.

Con las pruebas ya completas, el build de producción de TaskFlow como aplicación sigue exactamente el criterio fijado en la lección "Empaquetado, Publicación y TypeScript" (08-04, apartados 1 y 4): Vite, no Rollup de forma directa, porque TaskFlow es una aplicación autosuficiente, no una librería pensada para que otro bundler la vuelva a procesar.

El resultado, en dist/, queda con esta forma:

Cada nombre de fichero incluye un fragmento hash derivado de su contenido (a1b2c3d4, en el ejemplo), exactamente el mecanismo de control de caché explicado en 08-04: si el contenido de un fichero no cambia entre dos despliegues sucesivos, su nombre tampoco cambia, y el navegador de quien ya visitó TaskFlow puede seguir usando la copia que ya tiene en caché sin volver a descargarla. index.html, regenerado por Vite en cada build, ya apunta a los nombres de fichero correctos de esa build concreta, sin que haga falta editar manualmente ninguna ruta.

TaskFlow, como aplicación completa, se despliega con el build del apartado anterior. Pero cabe una pregunta distinta, ya planteada en abstracto en la lección 08-04: ¿merece la pena publicar <task-card> por separado, para que otros proyectos —no solo TaskFlow— puedan instalarla como dependencia de npm? Si la respuesta fuera afirmativa (algo razonable, dado que <task-card> no depende de ningún dato específico de TaskFlow salvo los que recibe como propiedades), el package.json de ese paquete independiente necesitaría declarar lit como dependencia externa, no incluida en el propio bundle, exactamente por el motivo explicado en 08-04 (apartado 3): evitar que dos componentes de terceros, ambos dependientes de Lit, carguen dos copias completas de la biblioteca en la misma aplicación.

peerDependencies es la pieza que formaliza esa decisión: declara que el paquete espera que quien lo instale aporte su propia copia de lit, en lugar de traer la suya incluida. devDependencies mantiene una copia de lit disponible solo durante el desarrollo del propio paquete (para poder ejecutar sus pruebas o su build), sin que esa copia viaje dentro del paquete final publicado. La configuración de Rollup, idéntica a la de la lección 08-04, produce el dist/task-card.js que este package.json referencia:

external: ['lit', /^lit\//] es el detalle que faltaba en el ejemplo de la lección 08-04: le indica a Rollup que no incluya, en el bundle final, ni el propio paquete lit ni ninguno de sus submódulos (lit/directives/..., lit/decorators.js), dejando esos import intactos en la salida para que el bundler de quien instale @taskflow/task-card los resuelva con su propia copia de Lit, coherente con la declaración de peerDependencies del package.json.

Ambos caminos son legítimos y no son mutuamente excluyentes: nada impide que TaskFlow se despliegue como aplicación completa (apartado 4) mientras, en paralelo, <task-card> se publica también como paquete independiente (apartado 5) para que otros equipos la reutilicen fuera de TaskFlow, exactamente el mismo componente en ambos casos, solo empaquetado de dos formas distintas según a quién va dirigido cada resultado.

Con TaskFlow ya probado, empaquetado y listo para desplegarse, merece la pena mirar atrás y recorrer, de un vistazo, el camino completo de este curso:

Ninguna fila de esta tabla es una sorpresa a esta altura del curso; se incluye aquí, en la última lección, precisamente para que el recorrido completo se vea de una sola vez, algo que ninguna lección anterior, centrada en su propio módulo, podía ofrecer.

Este curso ha cubierto Lit de forma exhaustiva para el tipo de aplicación que representa TaskFlow, pero el ecosistema alrededor de Lit sigue creciendo, y conviene dejar señalados algunos caminos concretos para quien quiera continuar más allá de esta última lección:

• @lit-labs/virtualizer: la lección "Rendimiento y Optimización" (09-03, apartado 9) mencionó la virtualización como técnica para listas de decenas de miles de elementos, fuera del alcance práctico de este curso, y señaló que TaskFlow no la necesitaba. Es, literalmente, el siguiente paso natural si <task-list> tuviera que crecer mucho más allá de los volúmenes de datos manejados en el módulo 9.
• @lit-labs/motion: un paquete experimental del propio ecosistema de Lit para animaciones declarativas entre estados, un terreno que esta lección solo ha tocado de forma manual con la animación CSS de resaltarSiUrgente (lección 10-02).
• @lit-labs/observers: controladores reactivos ya escritos por el equipo de Lit para envolver ResizeObserver, IntersectionObserver y otras APIs de observación del navegador, siguiendo exactamente el mismo patrón de ReactiveController estudiado en la lección 06-03 con ContadorTiempoRestanteController.
• Explorar Lit con TypeScript y decoradores más a fondo: la lección 08-04 presentó la equivalencia sintáctica entre static properties y decoradores; migrar progresivamente TaskFlow, componente a componente, es un ejercicio práctico natural para consolidar esa lección con un proyecto real.
• La documentación oficial en lit.dev: en particular su sección de recetas (Playground) y sus notas de cada versión, para seguir de cerca cualquier cambio futuro de la API a medida que Lit evolucione más allá de la versión estudiada en este curso.

Este curso empezó, en la lección "¿Qué son los Web Components y por qué Lit?", con una pregunta sobre estándares de la plataforma web y una promesa: aprender a construir interfaces reactivas con componentes propios del navegador, sin depender de un framework de aplicación completo. Diez módulos y treinta y nueve lecciones después, esa promesa se ha cumplido con una aplicación real y completa, TaskFlow, construida pieza a pieza, módulo a módulo, sin dejar ningún cabo suelto: cada concepto presentado se aplicó de inmediato sobre el propio proyecto, y cada pieza mencionada sin resolver del todo —desde <task-filter> en el módulo 5 hasta la animación de resaltarSiUrgente en esta última lección— encontró su lugar antes de que el curso terminara.

Quien haya seguido el curso completo, escribiendo y probando cada ejemplo, tiene ya el criterio necesario para abordar un proyecto real con Lit: cuándo levantar el estado a un ancestro común y cuándo recurrir a un contexto compartido; cuándo un controlador reactivo y cuándo un mixin; cuándo until y cuándo una propiedad de carga explícita; y, sobre todo, el hábito de preguntarse, ante cada decisión de diseño, cuál de las dos alternativas evita mejor los anti-patrones catalogados en el módulo 9. Ese criterio, más que la memorización de una API concreta, es lo que sobrevive una vez cerrado un curso.

Enhorabuena por haber llegado hasta aquí. TaskFlow queda terminado, probado y listo para desplegarse; el resto del camino, con Lit o con cualquier otra herramienta, queda ya en tus manos.

• Publicar una librería sin declarar lit como dependencia externa: como se explicó en el apartado 5, y ya se había advertido en la lección 08-04, olvidar external en la configuración de Rollup incluiría una copia completa de Lit dentro del paquete publicado, con el riesgo de duplicación ya conocido.
• Ejecutar vite build esperando el mismo resultado que para una librería: como recuerda la tabla del apartado 6, cada camino de despliegue tiene una herramienta y una configuración distintas; mezclar ambos objetivos en la misma configuración de build suele producir un resultado que no sirve bien para ninguno de los dos casos.
• Dar por buena una batería de tests incompleta solo porque el módulo 9 ya la empezó: como se ha visto en el apartado 2, <task-filter> y el flujo completo de tarea-cambiada no tenían ningún test hasta esta lección; conviene revisar, antes de dar cualquier proyecto por probado, qué piezas se añadieron después de la última vez que se escribieron tests.
• Tratar esta lección como el final del aprendizaje, no del curso: como señala el apartado 8, el ecosistema de Lit sigue vivo más allá de estas cuarenta lecciones; el criterio aprendido aquí es la base para seguir explorando, no un punto final.

1. Añade un test a test/task-board.test.js que compruebe que, tras cambiar el texto de búsqueda en el <input> de <task-filter> (accesible desde tablero.shadowRoot.querySelector('task-filter').shadowRoot.querySelector('input')), el número de <task-card> visibles dentro de <task-list> se reduce en consecuencia. Recuerda esperar updateComplete en cada nivel implicado, como en el test del apartado 3.
2. Completa el package.json del apartado 5 añadiendo un script "build": "rollup -c" y explica, basándote en la lección 08-04 (apartado 2), por qué este paquete usa Rollup mientras que la aplicación TaskFlow completa, en el apartado 4 de esta lección, usa Vite para el mismo verbo "hacer el build".
3. Repasa la tabla del apartado 7 y, para el módulo que consideres que aportó el cambio más importante en la arquitectura general de TaskFlow (no en una técnica concreta, sino en cómo se organizan los componentes entre sí), justifica tu elección con un ejemplo concreto del propio proyecto.

2. Este paquete usa Rollup porque su objetivo, tal como se explicó en la lección 08-04 (apartado 1) y se recordó en el apartado 6 de esta lección, es producir una librería reutilizable por otros bundlers, no una aplicación autosuficiente lista para servirse directamente; Rollup genera una salida limpia y cercana al código de entrada, pensada precisamente para que un bundler externo (el de quien instale @taskflow/task-card) la vuelva a procesar según sus propias necesidades. La aplicación TaskFlow completa, en cambio, no tiene ningún consumidor externo que vuelva a empaquetarla: su objetivo es el resultado final ya optimizado para el navegador, con división en fragmentos y gestión de caché por hash, que Vite ofrece de fábrica (usando Rollup por debajo, pero con una configuración orientada a aplicaciones, no a librerías).
3. Una respuesta razonable señala el módulo 5, con la aparición de <task-board>: antes de esa lección, <task-list> mantenía su propio array de tareas de ejemplo y no existía ningún componente capaz de coordinar más de dos niveles de la jerarquía; a partir de "Patrones de Comunicación entre Componentes Hermanos" (05-04), toda la arquitectura de TaskFlow pasó a organizarse alrededor de un ancestro común que reparte propiedades hacia abajo y recoge eventos hacia arriba, el mismo patrón que, ampliado con el contexto de filtro en el módulo 7, sigue vigente sin cambios estructurales hasta la versión final consolidada en este módulo 10. Otras respuestas igualmente válidas podrían señalar el módulo 7, por la introducción de @lit/context como alternativa al reenvío manual de propiedades, o el módulo 4, por la aparición de <user-avatar> como primer ejemplo de descomposición en un componente hijo reutilizable.