Cambiar un monorrepositorio grande y tipado sin romper otros paquetes

## Encontrar el paquete responsable antes de editar Comienza en la raíz del repositorio e identifica el paquete responsable del comportamiento solicitado. - Distingue las bibliotecas centrales, las integraciones con marcos de trabajo, las aplicaciones desplegables, los ejemplos y las herramientas internas. - Lee la guía de la raíz y la guía de paquete más cercana; la guía más específica rige el comportamiento del paquete. - Confirma el entorno de ejecución fijado, el gestor de paquetes, la disposición del espacio de trabajo y la compilación previa necesaria antes de ejecutar comandos de desarrollo. - No des por sentado que existe un servidor de desarrollo en la raíz. Inicia el paquete responsable o usa el filtro del espacio de trabajo que incluya sus dependencias ascendentes. - Antes de cambiar un consumidor, rastrea los tipos, las utilidades, los estilos y los recursos generados compartidos hasta su paquete canónico. - Mantén el cambio en el paquete responsable más pequeño, salvo que el contrato público abarque realmente varios paquetes. ## Seguir las reglas de compilación y dependencias de cada paquete Elige la ruta de compilación que corresponda al paquete, en lugar de imponer una sola herramienta a todo el espacio de trabajo. - Usa una compilación orientada al compilador para las bibliotecas puramente tipadas y un empaquetador de componentes para los paquetes de interfaz. - Externaliza las dependencias en la salida de la biblioteca; usa una compilación autónoma explícita solo cuando el entregable deba incluir sus dependencias de ejecución. - Mantén las dependencias internas en el protocolo del espacio de trabajo y obtén las versiones compartidas de terceros del catálogo central de versiones. - Importa los tipos compartidos desde sus puntos de entrada documentados, no desde una raíz de paquete demasiado amplia. - Cuando un paquete publique varios formatos, verifica cada salida declarada y sus declaraciones de tipos. - Trata la configuración de compilación, los archivos de bloqueo, la configuración compartida del compilador y los catálogos del espacio de trabajo como archivos de amplio impacto que requieren una validación más extensa. ## Reutilizar las utilidades compartidas antes de escribir código nuevo Busca en el paquete compartido de funciones auxiliares antes de escribir una utilidad nueva. Revisa las funciones auxiliares existentes para matrices, objetos, cadenas, URL, HTTP, JSON, Markdown, errores, archivos, colas, formato, expresiones regulares y pruebas. Reutiliza directamente una función adecuada. Añade una función nueva al paquete compartido solo cuando ningún comportamiento existente coincida y varios consumidores puedan usar la nueva abstracción. No crees implementaciones casi duplicadas en los paquetes de funcionalidades. Si el comportamiento existente es parecido, pero no exacto, compara los contratos, los casos límite, el impacto en el paquete generado y los puntos de llamada antes de decidir si lo amplías o mantienes una función local específica del dominio. ## Evitar `any` y tipar las funciones y las props de los componentes Escribe código que mantenga útil la inferencia y, al mismo tiempo, explicite los contratos públicos. - Prefiere los alias de tipos y las uniones de literales de cadena a las interfaces y las enumeraciones cuando así lo establezca el criterio de la base de código. - Asigna tipos de retorno explícitos a las funciones, usa `unknown` en lugar de `any`, marca las importaciones exclusivas de tipos y utiliza de forma predeterminada enlaces inmutables. - Mantén las importaciones directas; evita los archivos agregadores salvo en puntos de entrada de paquetes creados deliberadamente y evita las reexportaciones con comodines. - Nunca suprimas los errores de tipos de forma genérica. Usa una directiva de error esperado solo con una razón que demuestre que el error es intencional. - Gestiona todas las promesas y no marques una función como asíncrona a menos que espere una operación. - En los archivos de componentes, asigna tipos a las propiedades y los eventos, desestructura los valores predeterminados, traslada la lógica de plantilla no trivial a valores calculados y sigue el orden de configuración establecido. - Escribe comentarios y documentación de la API para explicar por qué existe una restricción, no para repetir el código. ## Probar primero el paquete afectado, no todo el repositorio Ejecuta el ámbito de pruebas más pequeño que demuestre el cambio. 1. Coloca las pruebas unitarias junto a su código fuente y asigna a la suite de nivel superior el nombre del archivo. 2. Prefiere las afirmaciones sobre el comportamiento y las funciones puras; minimiza los simulacros y evita probar la estructura del marcado o los detalles de estilo cuando el contrato sea el comportamiento del usuario. 3. Ejecuta una vez el paquete afectado con un filtro de ruta explícito. Usa el modo de observación solo durante el desarrollo activo. 4. Ejecuta pruebas de integración para los adaptadores modificados y pruebas de extremo a extremo para los recorridos de usuario afectados. 5. Inicia los servicios locales de prueba necesarios y espera a que estén preparados antes de las pruebas que dependan de ellos; las pruebas unitarias no deben usar la red real. 6. Ejecuta la suite completa del monorrepositorio solo para una comprobación final de integración deliberada o un cambio amplio de contrato compartido. Trata por separado los fallos previos no relacionados: reprodúcelos fuera del ámbito del cambio, notifícalos como tales y no los etiquetes erróneamente como éxitos del entorno ni como fallos causados por el cambio. ## Pasar lint a los archivos cambiados y comprobar tipos en los paquetes afectados Determina el conjunto de archivos modificados y aplica cada herramienta solo a la sintaxis que le corresponda. - Ejecuta el analizador estático y el formateador del lenguaje tipado sobre los archivos tipados modificados. - Ejecuta el analizador de componentes y el formateador general sobre los archivos modificados de componentes, documentación, datos, estilos y configuración. - Comprueba los tipos de cada paquete afectado mediante su script del espacio de trabajo. - Busca exportaciones, archivos y dependencias sin usar antes de abrir o actualizar una revisión. - Exige que todas las comprobaciones pertinentes de análisis, formato, tipos, pruebas y código sin usar se superen sin errores. No uses un comando para todo el repositorio cuando un filtro de paquete ofrezca una señal más sólida con menos ruido no relacionado. Amplía la validación cuando cambie una configuración fundamental o cuando el análisis de dependencias muestre varios consumidores descendentes. ## Escribir los títulos de revisión con la forma type(scope) y añadir un changeset Usa una rama específica y descripciones convencionales del cambio en tiempo presente, con el ámbito del paquete pertinente. - Da a los títulos de las revisiones la forma semántica `type(scope): subject` usando un tipo de cambio permitido. - Incluye las referencias a tiques e incidencias en la descripción de la revisión con la palabra clave correcta de cierre o de no cierre; no entierres en comentarios los identificadores de seguimiento obligatorios. - Añade una sección específica de tiques cuando se proporcionen enlaces de seguimiento. - Para cambios publicables en paquetes, integraciones o aplicaciones, revisa el estado de las notas de versión y añade un conjunto de cambios de nivel patch o minor cuando deba avanzar la versión. No introduzcas un incremento major mediante el flujo de trabajo habitual. - Mantén visibles las soluciones temporales con un TODO y explica la condición para retirarlas. - Nunca confirmes cambios con fallos conocidos de análisis, tipos, pruebas o exportaciones sin usar. ## Revisar los cambios de interfaz con capturas, en el entorno de prueba donde se ven Compila los paquetes ascendentes y después elige el entorno de prueba que exponga de forma más directa el comportamiento modificado. - Usa el catálogo de componentes para los controles básicos, la superficie de documentación para el renderizado y la navegación, y la superficie del cliente para la edición, la autenticación, las solicitudes y las respuestas. - Comprueba las superficies secundarias cuando los componentes compartidos, los temas, el renderizado de sintaxis o los iconos se propaguen a varios productos. - Captura imágenes del antes y el después para la interfaz modificada, imágenes contextualizadas para el comportamiento nuevo y una grabación breve para las interacciones. - Usa nombres descriptivos para los artefactos e inserta las pruebas en una sección visual específica de la descripción de la revisión. - Si un cambio afecta a varias superficies o disposiciones, captura cada resultado sustancialmente distinto en vez de tratar una sola imagen como prueba universal. Los artefactos visuales complementan las pruebas automatizadas; no sustituyen las afirmaciones de comportamiento, las comprobaciones de accesibilidad ni la validación de tipos. ## Usar los términos exactos del proyecto e informar solo de las comprobaciones hechas Usa de forma coherente el glosario del proyecto en el código, la documentación, las pruebas y el texto de las revisiones. Distingue un formato de protocolo de una descripción de API, un esquema de datos de un documento y la desreferenciación de la resolución; distingue también el empaquetado de estas dos últimas operaciones. Antes de finalizar: - revisa la diferencia final y confirma que todos los archivos modificados pertenecen al ámbito previsto; - verifica, según corresponda, la compilación, las pruebas, el análisis, el formato, los tipos, la búsqueda de código sin usar y las pruebas visuales; - confirma que los puntos de entrada de los paquetes, los catálogos de dependencias y los conjuntos de cambios concuerdan con la implementación; - enumera cualquier comprobación que no haya podido ejecutarse y conserva las pruebas exactas de su fallo; - no afirmes haber obtenido un resultado de todo el monorrepositorio cuando solo se haya ejecutado una comprobación limitada a un paquete. Informa de los paquetes afectados, los comandos ejecutados, los resultados directos, los riesgos residuales y cualquier trabajo aplazado deliberadamente.