Cambiar y probar código en un monorepo grande con muchos paquetes

## Localizar paquetes y puntos de entrada antes de editar - Identifique la estructura del espacio de trabajo, los paquetes publicados, los componentes nativos, las suites de pruebas, los ejemplos, la documentación y los scripts de mantenimiento. - Localice el árbol de código fuente del paquete principal, la salida compilada, los puntos de entrada de línea de comandos, los puntos de entrada del servidor y el punto de entrada de la compilación. - Siga el punto de entrada pertinente antes de cambiar el comportamiento; no deduzca la propiedad basándose únicamente en el nombre de un archivo. - Antes de editar un archivo anidado, lea todos los `README.md` aplicables desde la raíz del repositorio hasta el directorio de destino. - Trate la salida generada y los directorios de dependencias únicamente como evidencia para búsquedas. Modifique su fuente o generador en vez de editar directamente los archivos generados. ## Mantener la compilación al día y elegir una compilación parcial o completa - Después de cambiar de rama o inicializar un espacio de trabajo de estado incierto, ejecute la compilación de arranque completa para actualizar las salidas de los paquetes dependientes. - Para el trabajo iterativo sobre el código fuente o las pruebas de integración, inicie la compilación en modo de observación del paquete antes de editar, salvo que ya esté ejecutándose. - Un cambio solo de documentación, una investigación de solo lectura o un análisis limitado a CI pueden omitir el modo de observación, pero debe registrarse el motivo. - Use la compilación específica del paquete cuando los cambios permanezcan dentro de un solo paquete. Use la compilación completa cuando el trabajo abarque varios paquetes o cambie código nativo. - Para los errores de tipos, prefiera la comprobación de tipos específica a una compilación completa cuando proporcione evidencia equivalente. - Detenga cualquier proceso de observación que haya iniciado una vez finalizada la tarea. ## Elegir pruebas que coincidan con el modo de desarrollo o de producción - Elija el comando de prueba que coincida exactamente con el comportamiento de desarrollo o producción y con la implementación prevista del empaquetador o del entorno de ejecución. - Vuelva a compilar el código fuente afectado antes de ejecutar las pruebas de integración; una salida compilada obsoleta invalida el resultado. - Ejecute primero el archivo de prueba o patrón de nombre pertinente más específico y amplíe el alcance solo cuando el fallo o la superficie del cambio lo exijan. - Reproduzca CI con el mismo comando, modo, flags de funcionalidad y nombres de variables de entorno. Las pequeñas diferencias de modo pueden cambiar la resolución y las instantáneas. - No sustituya una prueba de integración por una prueba unitaria conveniente cuando la afirmación incluya la resolución de paquetes, el empaquetado, el arranque o el comportamiento del navegador. - Cuando los flags de funcionalidad habiliten implícitamente un comportamiento, pruebe la suite normal con ese flag en vez de depender únicamente de suites específicas heredadas. ## Escribir pruebas que esperen condiciones en lugar de pausas fijas - Use el generador de pruebas del repositorio, incluidos sus argumentos no interactivos, para que los fixtures y la configuración del arnés sigan las convenciones locales. - Prefiera los auxiliares de reintento basados en condiciones y con aserciones a las esperas fijas. Los retrasos fijos son lentos y siguen expuestos a condiciones de carrera. - Sustituya los auxiliares de sondeo obsoletos por el patrón compatible de reintento y aserción. - Prefiera directorios de fixtures reales a mapas grandes de archivos en línea para que las pruebas se parezcan a proyectos reales y sigan siendo mantenibles. - En las pruebas específicas de un modo, ejecute la guarda del modo antes de iniciar manualmente un servidor cuando el arnés requiera un arranque diferido. - Controle la precarga y el estado de navegación dentro del límite de sincronización de la prueba; evite las acciones del historial que restauran el estado almacenado en caché y desencadenan trabajo sin control. ## Guardar la salida de pruebas y compilaciones en lugar de repetirlas - Capture una vez la salida completa de una prueba o compilación y luego busque y resuma la salida guardada, en lugar de volver a ejecutar la misma suite con filtros distintos. - Para archivos de más de unas 500 líneas, busque primero los símbolos pertinentes y lea únicamente los intervalos circundantes. - Busque en los directorios generados solo cuando sea necesario para confirmar el comportamiento emitido; no los examine como fuente principal. - Agrupe las ediciones relacionadas antes de ejecutar la siguiente compilación y use la comprobación más rápida que demuestre la hipótesis actual. - Almacene en caché las respuestas de estado remoto durante una investigación y analice la respuesta guardada desde varios ángulos en vez de obtenerla repetidamente. - Conserve la salida exacta del fallo, el comando, el modo y el entorno como evidencia para el siguiente paso de diagnóstico. ## Reproducir los fallos de CI y corregirlos antes que los comentarios de revisión - Use la herramienta de análisis de estado del repositorio cuando exista e identifique si se está examinando la rama actual o una solicitud de cambio explícita. - Aborde los fallos bloqueantes en este orden, salvo que la evidencia indique lo contrario: compilación, formato o lint, tipos y, por último, pruebas. - Trate los fallos como reales hasta que se demuestre lo contrario. Un comportamiento inestable conocido aporta contexto a la investigación, pero no da permiso para descartar un fallo. - Reproduzca con el mismo modo de CI y los mismos flags de entorno, especialmente cuando haya distintos empaquetadores o rutas de ejecución disponibles. - Para los fallos de resolución de módulos o del grafo de compilación, ejecute el comando de integración normal específico del modo a fin de ejercitar el grafo real de paquetes. - Separe los fallos de CI de los comentarios de revisión, resuelva primero la evidencia de ejecución bloqueante y conserve un registro conciso de lo reproducido. ## Conectar los flags de funcionalidad en la compilación y en el entorno de ejecución - Añada un nuevo flag de funcionalidad a su tipo público, esquema de validación y punto de inyección en tiempo de compilación cuando lo consuma código empaquetado por el usuario. - Si el código precompilado del entorno de ejecución consume el flag, conecte también el valor de ejecución a través de cada ruta pertinente de servidor o worker. - No suponga que la inyección en tiempo de compilación destinada al código del usuario controla los componentes internos precompilados del entorno de ejecución. - Mantenga las cargas condicionales de módulos dentro de ramas `if` / `else` en tiempo de compilación para que la eliminación de código muerto pueda retirar las dependencias inalcanzables. - En entornos de ejecución restringidos, fuerce a `false` los flags que protegen las importaciones de plataformas no compatibles. - Mantenga las importaciones específicas del entorno de ejecución en su módulo de entrada designado y exponga el comportamiento necesario mediante la fachada pública de ese módulo. - Use una señal específica del entorno de ejecución para distinguir un servidor de desarrollo activo de una compilación de depuración; una etiqueta de entorno genérica puede describir ambos. - Marque para revisión de seguridad cualquier nuevo encabezado de solicitud entrante no estándar, salvo que la capa de entrada lo elimine o autentique. ## No dejar secretos en los registros y detenerse si falla la autenticación - Trate los valores de las variables de entorno como información sensible, salvo que sean flags de modo de prueba documentados. - Nunca imprima, pegue, haga commit ni coloque tokens, claves, cookies o valores secretos en registros compartidos, texto de revisión o ejemplos. - Replique los nombres y modos de las variables de CI sin insertar sus valores. Si falta un secreto necesario, deténgase y solicítelo mediante el canal aprobado. - Use marcadores de posición al documentar la configuración y nunca haga commit de archivos locales de secretos. - Si falla la autenticación del control de versiones porque no está disponible un agente de firma, proveedor de claves o credencial respaldada por hardware, deténgase y pida al usuario que la desbloquee. - No cambie los protocolos ni las direcciones remotas, no repita la operación fallida ni intente una solución alternativa de autenticación sin aprobación explícita. ## Comprobar los permisos antes de publicar solicitudes de cambio o comentarios - Antes de crear o editar una solicitud de cambio, incidencia, debate o comentario remoto, determine si la contribución procede de una rama interna o de una bifurcación externa. - Verifique la política de contribuciones del repositorio y la autorización del usuario antes de escribir en su nombre. - Si la autorización es insuficiente, no se haga pasar por responsable de mantenimiento ni publique todo el contenido de forma remota. Ofrezca datos técnicos, revise el texto escrito por el usuario e indique la vía de envío controlada por este. - Aplique las excepciones documentadas de manera restringida y solo después de verificar sus condiciones. - Mantenga las solicitudes de cambio recién creadas en estado de borrador, salvo que el usuario decida explícitamente que están listas para revisión. - Las escrituras remotas requieren un alcance explícito; el análisis y la reproducción locales no implican permiso para publicar. ## Dividir el trabajo en pasos pequeños y comprobar cada uno - Divida una tarea grande en pasos pequeños cuyos resultados puedan comprobarse de forma independiente. - Verifique cada paso antes de pasar al siguiente con el método acorde a su riesgo: inspección, formato, lint, tipos, pruebas unitarias, pruebas de integración, compilación u observación en tiempo de ejecución. - Cuando el método de verificación correcto no esté claro, pregunte antes de afirmar que el paso está completo. - Antes de hacer commit, ejecute en los archivos modificados la misma configuración de formateador y linter que utiliza el hook de commit del repositorio. - Revise el diff final en busca de ediciones no relacionadas, ruido generado, material secreto y pruebas o documentación que falten. - No informe de la finalización sin identificar la evidencia que respalda el comportamiento modificado. ## Detectar binarios nativos obsoletos e instantáneas que no coinciden - La búsqueda de mapas de código fuente puede requerir un flag explícito del entorno de ejecución y las rutas del código fuente pueden diferir entre compiladores; pruebe las formas de ruta conocidas. - Tenga en cuenta el directorio de trabajo actual al comparar trazas de pila de pruebas y producción. - Tras cambiar de rama, sospeche de binarios nativos obsoletos cuando el comportamiento contradiga el código fuente; actualice el artefacto gestionado por dependencias mediante la ruta de arranque aprobada. - Ante un error interno del compilador, elimine solo la caché de compilación incremental afectada y vuelva a intentarlo una vez antes de escalarlo. - Use el formateador oficial para el código en lenguaje nativo y prefiera importaciones basadas en la raíz del repositorio, salvo dentro de módulos de prueba en línea con alcance muy restringido. - La salida de las instantáneas puede variar según los flags y la implementación del entorno de ejecución, por lo que debe actualizarlas solo bajo el entorno exacto utilizado por el trabajo de CI de destino. - En los bloques de código de la documentación, vuelva a contar las líneas mostradas después de editar y confirme que cada resaltado apunte a la sentencia prevista.