El workspace: editar tu proyecto desde el navegador
Conectar una carpeta local para que los cambios del panel se escriban en tus ficheros, en qué se diferencia de los overrides, y cuándo compensa cada uno.
El workspace conecta una carpeta de tu disco con los recursos que la página carga, de forma que editar en el panel de Sources o en el de estilos escribe directamente en tus ficheros de proyecto. Suena parecido a los overrides y es conceptualmente lo contrario: los overrides sustituyen lo que el servidor manda por algo tuyo, mientras que el workspace identifica lo que el servidor manda como tuyo y te deja editarlo en origen. La diferencia decide para qué sirve cada uno.
- Conectar una carpeta local y verificar que la correspondencia se estableció.
- Distinguir workspace de overrides y elegir el adecuado según la situación.
- Usar la edición persistente de CSS desde el panel de estilos.
- Reconocer los casos donde la correspondencia falla y por qué.
Conectar una carpeta
En la sección de sistema de ficheros del navegador de Sources se añade una carpeta y se concede permiso de escritura. A partir de ahí, las DevTools intentan emparejar cada recurso cargado por la página con un fichero de esa carpeta.
El emparejamiento se hace por contenido, no por ruta: las DevTools comparan lo que llega de la red con lo que hay en disco y establecen la correspondencia cuando coinciden. Los ficheros emparejados aparecen con un distintivo verde en el árbol.
Esa forma de emparejar tiene una consecuencia importante: funciona con ficheros servidos tal cual y falla con ficheros transformados. Un CSS servido directamente se empareja; un CSS compilado desde otro lenguaje o procesado por un post-procesador, no, porque el contenido de la red no coincide con el del disco.
Existe un mecanismo de configuración automática por el que un servidor de desarrollo puede declarar la carpeta del proyecto mediante un fichero JSON servido en una ruta bien conocida bajo /.well-known/. Varios servidores de desarrollo modernos lo generan, y con él las DevTools proponen la conexión sin que haya que seleccionar la carpeta a mano. Es reciente y su disponibilidad depende de la versión, así que la conexión manual sigue siendo la vía fiable.
Workspace frente a overrides
Los dos escriben en disco y ahí acaba el parecido.
| Workspace | Overrides | |
|---|---|---|
| Qué carpeta | Tu proyecto real | Una carpeta aparte |
| Qué hace | Edita el fichero fuente | Sustituye la respuesta de red |
| Efecto en el servidor | El servidor sirve tu cambio en la siguiente carga | El servidor no se entera |
| Para qué sirve | Desarrollo local | Investigar un entorno que no controlas |
| Riesgo si se olvida | Ninguno, es tu código | Alto, el bug fantasma |
| Funciona con código transformado | No, o con dificultad | Sí, sobre el resultado |
La regla de elección es directa. Si controlas el servidor y el código no está transformado, workspace. Si el código pasa por un empaquetador, tu editor y la recarga en caliente ya hacen ese trabajo mejor. Si no controlas el entorno, overrides.
Editar CSS de forma persistente
El caso donde el workspace sigue siendo genuinamente útil incluso con herramientas modernas. Cuando una hoja de estilos se sirve directamente desde disco sin procesar, conectar la carpeta hace que cada cambio en el panel de estilos se escriba en el fichero.
Eso convierte el ajuste visual de espaciados, colores y tamaños en algo que no hay que trasladar después: mueves el valor con las flechas mirando la página, y el fichero queda con el valor final. Con la pestaña de cambios se puede además revisar el diff completo antes de dar por bueno el trabajo.
Para proyectos con un preprocesador o con estilos en JavaScript, esto no aplica, y la alternativa es lo de siempre: ajustar en el panel, revisar la pestaña de cambios, y trasladar a mano.
Cuando la correspondencia falla
Cuatro causas, en orden de frecuencia.
El fichero está transformado. Ya visto. Sin coincidencia de contenido no hay emparejamiento.
El fichero tiene finales de línea distintos. Un fichero con finales de línea de Windows en disco y servido con conversión no coincide byte a byte. Es una causa sorprendentemente frecuente en equipos mixtos.
La codificación difiere. Un fichero guardado con marca de orden de bytes y servido sin ella, o al revés.
El servidor añade algo. Algunos servidores de desarrollo inyectan un script de recarga en caliente en el HTML, lo que impide emparejar el documento aunque los ficheros de JavaScript sí se emparejen.
El diagnóstico de las cuatro es el mismo: comparar lo que llega de la red con lo que hay en disco. La pestaña de red muestra la respuesta cruda, y el editor muestra el fichero local.
El caso de los source maps y el workspace
Hay una combinación que funciona bien y merece conocerse: cuando hay source maps con sourcesContent, las DevTools pueden emparejar el fuente original reconstruido por el mapa con el fichero correspondiente de tu carpeta.
Eso significa que en un proyecto con empaquetador se puede editar el .ts o el .jsx original desde el panel de Sources y que el cambio se escriba en tu fichero de verdad. Después hace falta que el empaquetador recompile, cosa que hará solo si está vigilando la carpeta.
Es un flujo que a poca gente le compensa frente a usar su editor, y es útil en un caso concreto: cuando ya estás dentro del depurador, has encontrado la línea, y el cambio es de una palabra. Corregirlo ahí mismo sin cambiar de aplicación ahorra el salto de contexto.
Todo este nivel gira alrededor de una idea que conviene enunciar de forma explícita porque organiza las cuatro herramientas: en cualquier momento hay varias copias de tu código y hay que saber cuál manda. Está el fichero en tu editor. Está el artefacto que el empaquetador produjo. Está lo que el servidor sirve, que puede ser una compilación anterior. Está lo que el navegador tiene en caché, que puede ser más antiguo todavía. Está lo que el source map reconstruye, que puede corresponder a otra versión. Está el override en tu carpeta local, que gana a todo lo demás sin avisar. Y está lo que el motor de JavaScript tiene realmente cargado en memoria, que es lo único que se está ejecutando. Siete copias, y en un día normal las siete coinciden y nadie piensa en ello. El problema aparece cuando una se desalinea, porque entonces empiezas a razonar sobre un código que no es el que corre, y todo lo que deduzcas será correcto respecto a un artefacto irrelevante. Los síntomas son reconocibles una vez los conoces: un cambio que no surte efecto por mucho que recargues; un breakpoint que no se dispara aunque el código evidentemente se ejecuta; un console.log que no aparece; un comportamiento que contradice una línea que estás leyendo. Los cuatro significan lo mismo. La verificación decisiva es siempre bajar hasta la copia que manda, y en JavaScript esa copia se consulta con una sola expresión: String(laFuncion) en la consola devuelve el cuerpo que el motor tiene cargado, sin pasar por editores, mapas, cachés ni overrides. Si ese texto no es el que esperabas, ya no tienes un bug de lógica: tienes un problema de cadena de suministro, y la lista de siete copias de arriba es exactamente el orden en el que hay que ir buscando dónde se rompió.