Définir le besoin de diffusion des sources
Une carte de sources relie un fichier JavaScript transformé aux fichiers à partir desquels il a été construit. Elle aide à comprendre une erreur dans les outils du navigateur ou dans un système de diagnostic. Sur WordPress, elle peut accompagner le script d’un thème, d’une extension ou du code propre au projet. Avant de la retirer, identifiez son propriétaire et l’usage de diagnostic qui dépend de sa disponibilité.
La politique peut autoriser des cartes publiques pour un composant distribué librement, réserver les cartes du projet à une plateforme privée d’erreurs ou conserver seulement les fichiers nécessaires au navigateur. Faites préciser cette politique par le responsable du code. Le fichier JavaScript livré au navigateur reste lui-même accessible selon la route utilisée. La maîtrise des cartes concerne donc leur contenu supplémentaire, leur lieu de stockage et les références qui les rendent découvrables.
Commencez avec un script et une version identifiés. Une recherche de tous les fichiers portant une extension map sur le serveur ne suffit pas à savoir lesquels sont publiés. Inversement, certaines cartes peuvent être intégrées dans le script ou servies depuis un autre hôte. Le contrôle doit rapprocher le paquet, la réponse HTTP et les observations du navigateur.
Relier la page au script et à son paquet
Sur une copie représentative, ouvrez une page qui charge le composant concerné et relevez l’adresse du script dans le panneau Réseau. Notez le chemin, le nom de version et le type de réponse. Un outil d’optimisation peut combiner ou réécrire les scripts, ce qui produit un fichier différent de celui du paquet d’origine. Identifiez alors le composant qui effectue cette transformation et le moment où il génère la ressource.
Rapprochez l’URL publique du fichier présent dans l’artefact approuvé. Vérifiez la version déployée et la référence du pipeline. Un nom contenant un hash aide à distinguer des livraisons, mais il doit être confirmé par le manifeste de construction. Sur plusieurs frontaux, demandez quel paquet fournit la réponse. Conservez la racine et le numéro de version dans le dossier privé pour éviter une comparaison avec une reconstruction locale différente.
Si le script appartient à un éditeur tiers, consultez sa politique de distribution et sa documentation de diagnostic. Une suppression manuelle dans le dossier de l’extension peut être annulée lors de la prochaine mise à jour. Faites traiter la diffusion au niveau du mécanisme qui publie réellement les fichiers du composant.
Rechercher la référence de carte dans les outils du navigateur
Dans Chrome DevTools, utilisez les panneaux Sources et les ressources de développement pour voir si une carte est associée au script. Les réglages de prise en charge des cartes influencent leur chargement dans les outils. Relevez l’adresse annoncée, le résultat de chargement et le message d’erreur éventuel. Une carte absente du panneau peut être indisponible, mal référencée ou simplement non demandée par ce contexte. Comparez avec la réponse du script et les réglages du navigateur.
Inspectez la référence sourceMappingURL dans le fichier et l’en-tête SourceMap lorsqu’il est présent. Une référence peut être relative au fichier, absolue ou intégrée sous forme de données. L’en-tête peut prendre la priorité décrite dans la documentation sur une annotation du fichier. Demandez au mainteneur de confirmer la résolution de l’adresse lorsque plusieurs transformations interviennent. Évitez de suivre automatiquement une référence vers un hôte extérieur qui ne fait pas partie du périmètre autorisé.
Consignez la relation entre la page, le script livré et sa carte. Une capture des outils doit rester expurgée si elle affiche des chemins internes ou des noms de projet. Les messages de démonstration utilisés pour la preuve doivent éviter les données de clients.
Relever les en-têtes de la ressource servie
Pour un script public du périmètre, la commande suivante affiche les en-têtes d’une requête ordinaire et écarte le corps dans un terminal Unix. Remplacez le chemin d’exemple par celui relevé dans le navigateur. Elle ne suit pas les redirections. Vérifiez le statut, le type de contenu et les en-têtes avant d’attribuer une référence au script attendu. Une page de refus ou une réponse d’un frontal peut contenir d’autres informations.
Si la carte est référencée sur une autre route autorisée, relevez son statut et son type sans déclencher un programme ni exécuter son contenu. Une carte est un document de données à examiner, pas un script à lancer pour vérifier son rôle. Utilisez un stockage privé pour toute copie nécessaire. Les références peuvent contenir un chemin interne ou une URL signée, à protéger selon leur usage.
Comparez le relevé à la réponse réellement chargée par le navigateur. Une variante mise en cache ou une transformation du réseau peut présenter une autre référence. Gardez les observations datées pour le script et pour la carte. Une suppression dans le paquet ne prouve pas que toutes les copies publiées sont devenues inaccessibles.
L’option -q doit rester le premier argument pour ignorer les options implicites du fichier curlrc. Utilisez l’exécutable curl prévu et conservez les paramètres de proxy applicables. Un transfert incomplet ou un statut de refus ne prouve pas l’absence de carte. Pour le navigateur, vérifiez Settings > Preferences > Sources > JavaScript source maps, puis la ressource correspondante dans Developer Resources. Cette activation ne doit conduire à examiner que les adresses attribuées au périmètre.
curl -q --silent --show-error --max-time 15 --dump-header - \
--output /dev/null 'https://recette.example/assets/application.js'Examiner le contenu supplémentaire de la carte
Sur la copie privée, faites examiner les champs qui décrivent les sources, les noms et les contenus éventuellement embarqués. Une carte peut contenir les textes d’origine, des chemins de construction ou des noms de modules. Une autre peut contenir seulement les correspondances et des références vers les sources. Dans un éditeur JSON local, examinez sources pour les chemins, sourcesContent pour les textes embarqués et sourceRoot pour leur racine éventuelle. Comparez aussi les noms exposés à la politique du projet ; une liste de chemins peut suffire à révéler une structure interne. Le contenu exact dépend du mode de génération. Une extension map vide ou un fichier qui ne correspond pas au script ne permet pas d’évaluer la livraison actuelle.
Relevez les catégories d’informations que le propriétaire veut conserver privées. Par exemple, des chemins internes, du code de projet non prévu pour distribution ou des références de service peuvent justifier une modification de la chaîne de publication. Si vous découvrez une valeur qui constitue un secret utilisable, faites traiter son exposition et sa rotation par le responsable du service. Le simple retrait de la carte ne rend pas ce secret de nouveau confidentiel dans les copies déjà reçues.
Vérifiez aussi le fichier JavaScript publié et les autres artefacts du même paquet selon le besoin d’analyse. Une valeur peut avoir été intégrée au code final indépendamment de la carte. La décision sur les sources doit s’appuyer sur le paquet entier concerné, avec une portée explicite.
Choisir la publication adaptée au diagnostic
Pour un composant du projet, demandez au responsable de la construction comment les cartes sont générées et livrées. Les outils de compilation peuvent proposer des variantes qui incluent les sources, qui omettent leur contenu ou qui produisent une carte externe sans référence dans le fichier. Avec webpack, hidden-source-map retire la référence dans le script mais produit encore une carte externe ; nosources-source-map retire les textes sources embarqués mais peut toujours révéler les noms de fichiers et leur structure. Ces choix ne constituent pas un contrôle d’accès. Le mode doit être choisi pour l’usage réel et testé sur l’artefact de production, car les règles de recette peuvent être différentes.
Si le diagnostic passe par une plateforme privée, prévoyez l’envoi des cartes au service autorisé avec la version correspondante et le retrait de ces cartes du paquet public selon la politique. Une carte qui reste sur le serveur à une URL connue demeure récupérable si le serveur l’autorise, même quand le script ne l’annonce plus. Confirmez les droits et le cycle de conservation du stockage privé.
Si les cartes doivent rester publiques, examinez ce qu’elles contiennent et faites approuver la diffusion. Le besoin de faciliter le support d’un composant libre peut justifier ce choix. La fiche doit alors préciser le propriétaire, les fichiers publiés et le contrôle qui garantit l’absence de données de construction non destinées à ce canal.
Préparer une livraison réversible
Conservez le paquet courant, le manifeste des scripts et cartes, les règles de serveur et la configuration de construction. Identifiez les fichiers qui changent et les outils qui les republient. Sur une copie, produisez le nouveau paquet avec la méthode habituelle. Vérifiez les références, les noms de fichiers et les emplacements publics. Une exclusion de fichier peut nécessiter un nettoyage de la destination si le déploiement se contente d’ajouter les nouveaux artefacts.
Préparez le retour du paquet et du diagnostic privé. Une livraison peut continuer à fonctionner dans le navigateur alors que le système de suivi d’erreurs ne retrouve plus la bonne carte. Définissez un test de démonstration qui vérifie les deux besoins sans produire d’incident réel. Conservez les références de version qui permettent d’associer une erreur à sa livraison.
Si le serveur doit refuser certaines cartes, limitez la règle aux chemins approuvés. Une interdiction globale d’une extension peut affecter un composant tiers ou un autre usage de fichiers. Faites examiner la portée par le responsable du serveur et vérifiez le résultat reçu à l’URL exacte. La règle d’accès et la construction du paquet demandent des validations complémentaires.
Vérifier le navigateur et les anciennes adresses
Après la livraison de recette, chargez une page fraîche qui utilise le script. Vérifiez son statut, son contenu attendu et les fonctions de démonstration. Consultez les outils de développement pour voir si une carte est encore demandée et si le résultat correspond à la politique. Un message de carte absente peut être acceptable dans un mode de publication prévu, mais il doit être compris et documenté par le mainteneur.
Demandez ensuite les anciennes adresses de cartes connues qui appartiennent au périmètre. Vérifiez si le serveur ou le frontal les sert encore et si elles devaient être retirées. Un nouvel artefact versionné ne supprime pas automatiquement les fichiers de versions précédentes. Demandez une purge ciblée des copies publiques lorsque le plan le prévoit, puis contrôlez la réponse à la même URL. Une URL différente ne démontre pas le retrait de l’ancienne.
Pour la plateforme de diagnostic privée, confirmez que la version de démonstration retrouve la carte appropriée et que son accès est limité aux rôles prévus. Conservez une preuve expurgée du rapprochement, sans exposer les sources dans un ticket plus largement partagé.
Traiter une référence qui revient après une optimisation
Si une carte ou sa référence réapparaît après un changement de cache ou d’optimisation, identifiez le composant qui a recréé le fichier. Un outil peut reconstruire un bundle à partir des sources du thème et publier ses propres ressources. Corrigez sa configuration de génération ou son canal de sortie selon sa documentation. Une suppression répétée à la main peut seulement masquer le problème jusqu’à la prochaine reconstruction.
Comparez le fichier servi avant et après cette étape avec son identifiant de version. Si la référence est dans un en-tête ajouté par le frontal, faites corriger ce niveau plutôt que le code du thème. Si elle vient d’une annotation dans le script, confirmez quelle version du paquet l’a produite. Une carte mise à jour sans le script correspondant peut rendre le diagnostic trompeur, même si les deux fichiers répondent correctement.
Gardez les observations de chaque étape. Le dossier doit montrer quelle opération crée la référence et quel mécanisme contrôle sa diffusion. Cela permet de choisir un changement durable et de tester sa persistance après la prochaine livraison normale.
Rétablir la fonction attendue en cas de régression
Si le nouveau paquet casse le comportement du site, remettez le paquet approuvé par le mécanisme de déploiement. Vérifiez les scripts, les fonctions métier et les références de diagnostic après retour. Le retrait d’une carte ne devrait pas être utilisé pour masquer une erreur du script final. Rapprochez la régression des changements de construction et des fichiers réellement livrés.
Si seule la lecture privée des erreurs est rompue, vérifiez l’identifiant de livraison et la correspondance entre la carte et le fichier transformé. Rétablissez le diagnostic selon le plan sans republier automatiquement toutes les sources. Le responsable peut choisir une solution temporaire limitée au service privé pendant l’examen du pipeline. Conservez l’heure du retour et les preuves du scénario de démonstration.
Pour une valeur sensible déjà diffusée, appliquez le traitement d’incident prévu même si les anciennes URL répondent maintenant par un refus. Des copies peuvent avoir été reçues avant la correction. La suppression du fichier public et le traitement du secret doivent donc être suivis séparément avec les propriétaires concernés.
Remettre la politique par paquet et par version
La fiche finale doit identifier le script, la carte, le mécanisme de génération et le canal de distribution. Ajoutez la politique approuvée, les références des fichiers courants et le résultat des anciennes adresses connues. Si le contrôle porte sur un seul composant, précisez-le. Une carte d’un thème examinée ne valide pas celles des autres extensions. Les informations retenues doivent permettre de reproduire le constat avec la même version.
Chrome DevTools et curl peuvent fournir les observations décrites sans abonnement supplémentaire. Les outils de construction et les plateformes privées de diagnostic ont leurs propres conditions, à vérifier pour le service réellement utilisé. La méthode n’impose pas de changer d’outil lorsque le projet possède déjà un circuit capable de maîtriser les artefacts.
Conservez les sources primaires et la version de configuration en interne. Programmez ce contrôle lors d’un changement de pipeline, d’un outil d’optimisation ou d’un prestataire de diagnostic. La prochaine personne pourra vérifier la diffusion du paquet et la capacité de diagnostic à partir d’un état attribué.
L’Atelier WordPress.
