Local overrides: editar producción de forma persistente
Sustituir cualquier recurso de la red por un fichero local, incluidas las cabeceras de respuesta, y usarlo para reproducir arreglos sin desplegar.
Un override local hace que el navegador, al pedir cierto recurso, use un fichero de tu disco en lugar de lo que devuelva el servidor. La página se comporta como si el servidor sirviera tu versión, y el cambio persiste entre recargas y entre sesiones. Es la herramienta que convierte “creo que el problema es esta línea de producción” en “he comprobado que cambiando esta línea de producción el problema desaparece”, que son dos afirmaciones con un abismo entre medias.
- Configurar una carpeta de overrides y sobrescribir recursos de red.
- Sobrescribir cabeceras de respuesta, incluidas las de CORS y las de caché.
- Reproducir y verificar un arreglo contra el entorno real sin desplegar nada.
- Reconocer los límites y el riesgo de dejar overrides activos sin darse cuenta.
Cómo se activan
En el panel de Sources hay una pestaña de overrides donde se selecciona una carpeta local y se concede permiso de escritura al navegador. A partir de ahí, una casilla activa el mecanismo globalmente.
Con eso hecho, hay dos formas de crear un override.
Desde el panel de Sources, abriendo el fichero y guardando los cambios. El fichero se copia a tu carpeta con la estructura de directorios que refleja la URL, y a partir de ese momento se sirve desde ahí.
Desde el panel de Network, con la opción de sobrescribir el contenido en el menú contextual de una petición. Es más cómoda cuando ya estabas mirando la red, y es la única vía para recursos que no aparecen cómodamente en Sources, como una respuesta JSON de una API.
Los recursos con override se marcan con un distintivo tanto en Sources como en Network, y el panel muestra un aviso cuando el mecanismo está activo. Ese aviso es importante y conviene aprender a verlo.
Los overrides son la intervención con mayor persistencia de todas las DevTools: sobreviven a recargas, a cerrar el navegador y a reiniciar la máquina. Un override olvidado hace semanas produce el bug fantasma más difícil de diagnosticar que existe, porque la explicación está en tu disco duro y no en ningún sitio donde a nadie se le ocurra mirar.
Qué se puede sobrescribir
Ficheros de JavaScript y de CSS. El caso principal. Permite probar un arreglo contra el código de producción real.
El documento HTML. Cambiar el marcado servido, añadir o quitar etiquetas, modificar los scripts que se cargan.
Respuestas de API. Sustituir el JSON que devuelve un endpoint por uno que tú controlas. Es la forma más rápida de probar cómo se comporta la interfaz con datos que no puedes producir fácilmente: una lista vacía, un campo nulo, mil elementos, un texto larguísimo, un carácter no latino.
Imágenes y fuentes. Menos frecuente y a veces útil para comprobar el comportamiento con un recurso de otro tamaño.
Cabeceras de respuesta. Merece su propio apartado.
Sobrescribir cabeceras
La opción de sobrescribir cabeceras, disponible desde el panel de Network, guarda un fichero especial en la carpeta de overrides con las reglas. Su formato es un array de objetos, cada uno con un patrón de coincidencia y la lista de cabeceras a aplicar.
[
{
"applyTo": "*",
"headers": [
{ "name": "cache-control", "value": "no-store" }
]
},
{
"applyTo": "api/*",
"headers": [
{ "name": "access-control-allow-origin", "value": "*" },
{ "name": "access-control-allow-headers", "value": "content-type, authorization" }
]
}
]Los casos donde esto resuelve un problema que no tiene otra solución rápida.
Diagnosticar CORS. Añadiendo las cabeceras que faltan se comprueba si el problema es exclusivamente de configuración del servidor. Si con ellas funciona, ya sabes qué pedirle al equipo de backend y con qué valores exactos.
Probar políticas de caché. Cambiar cache-control permite ver el comportamiento con la caché que tendrá el recurso en producción, sin esperar al despliegue.
Probar cabeceras de seguridad. Ajustar la política de seguridad de contenido para ver si es la que está bloqueando un recurso, o probar cabeceras de aislamiento de origen antes de configurarlas de verdad.
Simular un fallo. Cambiar un tipo de contenido para ver cómo responde el código a una respuesta mal etiquetada.
El flujo de reproducir un arreglo en producción
El uso que justifica toda la lección, paso a paso.
Reproduce el bug en producción con las DevTools abiertas. Localiza el fichero responsable, que con los source maps desplegados será tu fuente original.
Aplica el cambio que crees que lo arregla, directamente en el editor del panel, y guarda. Se crea el override.
Recarga. Como el override persiste, la página vuelve a cargar con tu versión.
Comprueba si el bug ha desaparecido.
Desactiva los overrides y recarga otra vez. El bug debe volver. Esta comprobación es la que convierte una coincidencia en una prueba, y es la que casi todo el mundo se salta.
Con eso tienes una verificación real contra el entorno real, antes de escribir una sola línea en tu repositorio. Y si el arreglo no funciona, lo has descubierto en dos minutos en lugar de después de un despliegue.
Los límites
No funciona con recursos que un service worker sirve desde su caché, porque la petición nunca llega al punto donde se aplicaría el override. Hay que saltarse el service worker o desregistrarlo.
No cambia lo que el servidor hace. Sobrescribir la respuesta de una API no cambia los datos: la próxima petición desde otro sitio devolverá lo original. Es una simulación del lado del cliente.
No funciona para peticiones que no pasan por la red del documento, como algunas iniciadas por extensiones.
La correspondencia es por URL exacta. Un recurso con un hash en el nombre —que es lo normal en producción— cambia de URL en cada despliegue, y el override deja de aplicarse silenciosamente. El síntoma es que tu cambio “deja de funcionar” sin que hayas tocado nada.
De todo lo que hacen las DevTools, hay una cosa que solo los overrides consiguen y que merece nombrarse con claridad, porque cambia el tipo de afirmación que puedes hacer. Todas las demás herramientas responden a preguntas de la forma “qué está pasando”: qué valor tiene esto, quién llamó a aquello, cuánto tardó lo de más allá. Son preguntas de observación, y responderlas es la mayor parte del trabajo. Pero la pregunta que decide si un arreglo es correcto es de otra clase: “si cambio esto, ¿desaparece el problema?”, y esa es una pregunta de intervención que solo se puede responder interviniendo. En desarrollo local se responde trivialmente porque puedes editar y recargar. En el entorno donde el bug de verdad ocurre —producción, o preproducción, o el despliegue de otro equipo, o una integración de un cliente— normalmente no puedes editar nada, y ahí es donde la mayoría de la gente se conforma con una hipótesis: “creo que es esto, vamos a desplegarlo y vemos”. Ese ciclo cuesta entre una hora y un día según el proceso de despliegue, y cuando falla —que falla a menudo, porque la hipótesis se formuló sin verificar— hay que empezar otra vez. Los overrides eliminan ese ciclo por completo: aplicas el cambio en el entorno real, recargas, y en treinta segundos sabes si tu hipótesis era correcta. Y hay un uso menos obvio y todavía más valioso que conviene tener presente: usar el override para verificar que el arreglo del compañero funciona antes de aprobar el cambio, o para reproducir el fallo de un cliente aplicando su configuración exacta sobre el entorno de producción. En los dos casos, la afirmación pasa de “según el código debería funcionar” a “lo he comprobado en el sitio donde falla”, que es una diferencia que cualquiera que haya desplegado un arreglo equivocado un viernes por la tarde sabe apreciar.