C’est une question pertinente que j’ai eu à répondre récemment et je vous fais part de mes différentes réflexions.
Voyons dans cet article pourquoi en réponse courte c’est une bonne idée pour moi de mettre en ligne ces fichiers .map
Définition
Les fichiers source .map sont essentiellement des fichiers générés lors de la construction du site web qui relie une version combinée/minifié/uglifiée d’un actif (CSS ou JavaScript) à son état d’origine.
La plupart des sources JavaScript et CSS sont généralement réduites et les fichiers source .map servent de carte mémoire pour les fichiers compressés. C’est généralement une bonne pratique de réduire et de combiner vos ressources (JavaScript et CSS) lors du déploiement en production. Ce processus réduit la taille de vos ressources et améliore considérablement le temps de chargement de votre site Web.
Lorsque vous réduisez et compressez vos fichiers JavaScript ou CSS, les fichiers de sortie sont généralement réduits, illisibles et totalement différents de la source originale créée par un développeur. Il s’agit en fait de l’un des moyens les plus simples d’améliorer les performances de votre site Web.
Lorsque vous construisez votre application pour la production, des fichiers source .map sont généralement générées avec vos fichiers construits qui sont déjà réduits. Ils contiennent les sources originales de votre code et vous aident à déboguer votre code en direct.
Avec les fichiers source .map, vous pouvez cliquer sur un certain numéro de ligne et de colonne dans votre JavaScript généré, et cela fera une recherche dans le fichier .map qui renverra l’emplacement original. La plupart des outils de développement peuvent maintenant analyser automatiquement les fichiers .map des sources et donner l’impression que vous exécutez les fichiers non minifiés et non combinés.
Si vous souhaitez comprendre plus en détail les idées qui se cachent derrière les fichiers
.map, consultez la spécification des fichiers sources.map.
Pour voir comment webpack gère les fichiers
.mapsource, voir source-map-visualization.
Exemple
Disons que vous avez un fichier appelé searchBox.module.scss qui est importé dans global.scss qui est compilé en global.css. C’est ce fichier CSS final qui est chargé dans le navigateur. Par exemple, lorsque vous inspectez un élément dans DevTools, il peut vous dire que le form est margin: 0;padding: 0; parce que c’est ce qui est indiqué à la ligne 13 du document searchBox.module.scss
Et Alors?
Ces fichiers source .map sont donc destinées aux développeurs. Ils sont particulièrement utiles pour vous et votre équipe, car elles aident énormément à déboguer les problèmes ainsi qu’au travail quotidien. Je suis sûr que je m’en sers presque tous les jours. Je dirais qu’en général, ils sont utilisés pour le développement local. Vous pouvez même les .gitignore ou les ignorer dans un processus de déploiement afin de servir et de stocker moins de ressources en production. Mais il y a eu quelques discussions récentes sur la nécessité de s’assurer qu’ils sont également utilisés en production.
Consultez ce fil de discussion pour une conversation plus intéressante sur l’envoi de fichiers source .map en production. Les avantages se résument à ces deux choses :
- Cela peut vous aider à localiser plus facilement les bogues en production.
- Cela permet à d’autres personnes d’apprendre plus facilement de votre site web.
Les deux sont cool. Personnellement, je serais opposé à l’envoi de code optimisé pour les performances à des fins d’apprentissage uniquement. L’envoi des fichiers source .map à la production est un bon compromis. Il n’y a pas d’impact sur les performances (les fichiers source .map ne sont pas chargées à moins que DevTools ne soit ouvert, ce qui, à mon avis, n’a rien à voir avec une véritable discussion sur les performances) et l’avantage de fournir des avantages en matière de débogage et d’apprentissage.
Et personnellement, si une personne est tentée d’en apprendre plus sur votre site, c’est que vous faites des trucs cool dessus non?
Les inconvénients évoqués dans les discussions récentes se résument à :
- Les plans de sources nécessitent un temps de compilation
- Ils permettent aux gens de, je ne sais pas, voler votre code ou autre chose.
Le point 2 ne m’intéresse pas (désolé), et le point 1 semble généralement négligeable pour un petit site ou ce que nous considérons comme un site moyen, bien que je craigne de ne pas pouvoir parler pour les méga sites.
Une chose que je devrais ajouter cependant est que les fichiers source .map peuvent même être générées pour les outils CSS-in-JS, donc pour ceux qui injectent littéralement des styles dans le DOM pour vous, ces cartes sources sont également injectées. J’ai constaté des ralentissements importants dans ces situations, je dirais donc qu’il ne faut surtout pas envoyer les fichiers source .map en production si vous ne pouvez pas les séparer de vos bundles principaux. Dans le cas contraire, je vous recommande vivement de le faire.
Conclusion
En résumé, pour moi, les fichiers source .map sont particulièrement utiles pour mon équipe et moi, car elles aident énormément à déboguer les problèmes. L’aspect du temps de génération qui est totalement négligeable comparativement au temps de débogage. Et il n’y a pas d’impact au temps de chargement de la page.
Et sellons-nous, est-il sûr d’envoyer des fichiers source .map en production ?
