Es una pregunta válida. Un “mapa de origen” es un archivo especial que conecta una versión reducida / mejorada de un activo (CSS o JavaScript) con la versión original. Digamos que tienes un archivo llamado _header.scss que se importa en global.scss que se compila para global.css. Ese archivo CSS final es lo que se carga en el navegador, así que, por ejemplo, cuando inspecciona un elemento en DevTools, puede decirle que el <nav> es display: flex; porque lo dice en la línea 387 en global.css.
En la línea 528 de page.css, podemos averiguar que .meta posee position: relative;
Pero debido a que ese archivo CSS final probablemente esté reducido (se eliminaron todos los espacios en blanco), es probable que DevTools nos diga que encontraremos la declaración que estamos buscando en la línea 1. Desafortunado y no útil para el desarrollo.
Ahí es donde entran los mapas de origen. Como dije arriba, los mapas de origen son archivos especiales que conectan el archivo de salida final que el navegador está usando con los archivos creados con los que realmente trabaja y escribe código en su sistema de archivos.
Normalmente, los mapas de origen son una opción de configuración del preprocesador. Estas son las opciones de Babel. Creo que con Sass, ni siquiera tienes que pasar una bandera en el comando ni nada porque produce mapas de origen de forma predeterminada.
Entonces, estos mapas de origen son para desarrolladores. Son particularmente útiles para usted y su equipo porque son de gran ayuda para depurar problemas y para el trabajo diario. Estoy seguro de que los utilizo casi todos los días. Yo diría que en general se utilizan para el desarrollo local. Incluso podrías .gitignore o sáltelos en un proceso de implementación para servir y almacenar menos activos para producción. Pero ha habido algunas conversaciones recientes sobre asegurarse de que también vayan a producción.
David Heinemeier Hansson:
Pero los mapas de origen se han considerado durante mucho tiempo simplemente como una herramienta de desarrollo local. No es algo que se envía a producción, aunque la gente también lo ha estado haciendo, de modo que la depuración en vivo sería más fácil. Eso en sí mismo es una gran razón para enviar mapas de origen. […]
Además, Rails 6 acaba de comprometerse a enviar mapas de origen de forma predeterminada en producción, también gracias a Webpack. Podrá desactivar esa función, pero espero que no lo haga. La web es un lugar mejor cuando permitimos que otros aprendan de nuestro trabajo.
Consulte el hilo de este tema para ver una conversación más interesante sobre el envío de mapas de origen a producción. Los beneficios se reducen a estas dos cosas:
- Podría ayudarlo a rastrear errores en producción más fácilmente
- Ayuda a otras personas a aprender de su sitio web más fácilmente
Ambos son geniales. Personalmente, me opondría a enviar código de rendimiento optimizado solo con fines de aprendizaje. Escribí sobre eso el año pasado:
No quiero que mi fuente sea legible por humanos, no por razones de protección, sino porque me preocupa más el rendimiento web. Quiero que mi sitio web llegue a la velocidad de la luz en una pequeña especificación de polvo de paquetes de red mágica y se convierta en un sitio web completo. O haga lo que la ciencia de la computación considere que es la forma más rápida de enviar datos de sitios web entre computadoras. Me preocupa mucho más el estado del rendimiento web que la educación web. Pero incluso si estaba muy preocupado por la educación web, no creo que sea el trabajo de la red ofrecer capacidad de aprendizaje.
Enviar mapas de origen a producción es un buen término medio. No hay impacto en el rendimiento (los mapas de origen no se cargan a menos que tenga DevTools abierto, lo cual, en mi opinión, es irrelevante para una discusión de rendimiento real) con el beneficio de brindar beneficios de depuración y aprendizaje.
Las desventajas planteadas en una discusión reciente se reducen a:
- Los mapas de origen requieren tiempo de compilación
- Permite a la gente, no sé, robar tu código o algo
No me importa el n. ° 2 (lo siento), y el n. ° 1 parece generalmente insignificante para un sitio pequeño o lo que consideramos el promedio, aunque me temo que no puedo hablar por mega sitios.
Sin embargo, una cosa que debo agregar es que los mapas de origen incluso se pueden generar para herramientas CSS-in-JS, por lo que para aquellos que literalmente inyectan estilos en el DOM, esos mapas de origen también se inyectan. He visto ralentizaciones importantes en esas situaciones, por lo que diría que definitivamente no envíe mapas de origen a producción si no puede dividirlos de sus paquetes principales. De lo contrario, votaría firmemente a favor de usted.