Le débogage des erreurs JavaScript en production est complexe : le code est minifié et chaque utilisateur dispose d'un appareil, d'un navigateur et de conditions réseau uniques. La plupart des solutions de surveillance du navigateur s'appuient sur l'objet *PerformanceTiming*, qui ne capture que le temps de chargement complet de la page et exclut les temps de chargement des ressources statiques, ce qui rend difficile l'identification des goulots d'étranglement en matière de performances. Browser Monitoring dans Application Real-Time Monitoring Service (ARMS) combine la prise en charge des source maps avec le suivi rétroactif du comportement des utilisateurs. Cela vous permet de faire correspondre les traces de pile minifiées au code source et de rejouer les actions exactes de l'utilisateur ayant déclenché une erreur.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Installé l'agent ARMS Browser Monitoring dans votre application. Pour obtenir des instructions de configuration, consultez Présentation de Browser Monitoring
Généré un fichier source map à l'aide de votre outil de build (consultez la section Générer des source maps)
Fonctionnement des source maps
Une source map est un fichier JSON qui établit une correspondance entre les positions dans le code minifié et les positions correspondantes dans votre code source original. Elle utilise l'encodage VLQ pour stocker les données de localisation de manière compacte. Grâce à une source map, Browser Monitoring traduit une erreur située à la « ligne 1, colonne 79585 » en un fichier, une ligne et une colonne précis dans votre code source.
Flux de travail de diagnostic
Le flux de travail suivant décrit le processus de bout en bout : identifier les tendances des erreurs, faire correspondre les traces de pile minifiées au code source, puis rejouer les actions de l'utilisateur ayant déclenché l'erreur.
Étape 1 : Consulter la vue d'ensemble des erreurs
Connectez-vous à la console ARMS.
Dans le volet de navigation de gauche, choisissez .
Sur la page Browser Monitoring, sélectionnez une région dans la barre de navigation supérieure et cliquez sur le nom de l'application que vous souhaitez gérer.
Dans le volet de navigation de gauche, cliquez sur JS Error Diagnosis.

Sur cette page :
La section Error Overview affiche le nombre total d'erreurs, le taux d'erreurs JS ainsi que le nombre et le pourcentage d'utilisateurs affectés.
Le graphique en courbes illustre l'évolution des erreurs dans le temps.
L'onglet Frequent Errors répertorie les erreurs les plus fréquentes.
Les onglets Page Ranked by Error Rate et Error View affichent la répartition des erreurs par page.
Étape 2 : Analyser une erreur spécifique
Deux points d'entrée sont disponibles :
Dans l'onglet Frequent Errors, cliquez sur Diagnose à côté de l'erreur cible.
Dans le graphique en courbes, cliquez sur un point de données à un moment donné pour ouvrir la boîte de dialogue Exception Insight.
L'exemple suivant utilise l'approche par graphique en courbes :
-
Sur le graphique en courbes, identifiez un point où le taux d'erreur augmente brusquement. Placez le curseur sur le point d'inflexion jusqu'à ce qu'il se transforme en icône de main, puis cliquez dessus. La boîte de dialogue Exception Insight s'affiche. Pour plus d'informations, consultez la rubrique Afficher les informations sur les exceptions.

Cliquez sur l'onglet Frequent Errors Top 5, sélectionnez une erreur, puis cliquez sur Diagnose dans la colonne Operation. L'onglet Error Detail s'affiche.
Étape 3 : Examiner les détails de l'erreur
La page de détail des erreurs fournit le contexte suivant :
| Champ | Description |
|---|---|
| Heure de première occurrence | Moment où l'erreur a été enregistrée pour la première fois |
| Version lors de la première occurrence | Version de l'application lorsque l'erreur est apparue pour la première fois (facultatif) |
| Nom et type de l'erreur | Nom et classification de l'erreur JavaScript |
| Heure d'occurrence | Moment où cette instance d'erreur s'est produite |
| Appareil, système d'exploitation, navigateur | Environnement client dans lequel l'erreur s'est produite |
| Adresse IP, région | Emplacement réseau de l'utilisateur |
| Type de connexion | Connexion réseau (Wi-Fi, 4G, etc.) |
| URL de l'erreur | URL de la page où l'erreur a été déclenchée |
| Version de l'application | Version déployée de l'application |
| Fichier, ligne, colonne | Position dans le fichier minifié |
Exemple : La capture d'écran suivante montre une erreur provenant d'un module de carte sur un tableau de bord en temps réel. Le module a signalé des données non valides lors d'une mise à jour, et la trace de pile pointe vers la ligne 1, colonne 79585 dans le bundle minifié.

« Ligne 1, colonne 79585 » n'est pas exploitable car le code de production est minifié. L'étape suivante consiste à faire correspondre cette position à votre code source.
Étape 4 : Faire correspondre l'erreur au code source
Les numéros de ligne et de colonne dans la trace de pile pointent vers du code minifié, et non vers vos fichiers sources. Appliquez une source map pour résoudre l'emplacement original de l'erreur.
Dans la section Stack Info, cliquez sur l'icône
à gauche d'un frame de pile pour le développer, puis cliquez sur Choose Sourcemap.-
Dans la boîte de dialogue Sourcemap File, sélectionnez un fichier source map existant ou téléchargez-en un nouveau, puis cliquez sur OK.
RemarqueVous pouvez télécharger jusqu'à cinq fichiers à la fois.

-
Après avoir appliqué la source map, Browser Monitoring met en surbrillance en rouge l'emplacement original de l'erreur dans la section Source Code, en affichant le fichier et la ligne exacts où l'erreur s'est produite. appliquez des source maps à chaque frame de la pile d'erreurs pour retracer la chaîne d'appels complète.
Étape 5 : Reproduire l'erreur grâce au suivi rétroactif du comportement des utilisateurs
Le mappage des source maps révèle où l'erreur s'est produite, mais pas toujours pourquoi. Dans l'exemple du module de carte, le mappage du code source montre que des données non valides ont provoqué l'erreur lors de la création du composant. Toutefois, le code source inclut déjà des vérifications de nullité et une tolérance aux pannes pour ces données. Pour comprendre pourquoi les données non valides sont apparues, examinez ce qui s'est passé immédiatement avant l'erreur.
Browser Monitoring enregistre le comportement des utilisateurs sous forme de trace chronologique de nœuds d'événements :
Chargement de la page
Modifications de route
Clics sur la page
Requêtes API
Sortie de console
Consultez cette trace pour rejouer la séquence d'actions ayant conduit à l'erreur.
Exemple : La trace de comportement utilisateur suivante montre qu'une requête API a eu lieu juste avant l'erreur. L'appel API demandait une mise à jour en temps réel pour le module de carte, mais la réponse a renvoyé ConsoleNeedLogin au lieu de données de carte valides. Cela indique que l'utilisateur s'était déconnecté de la page, ce qui constitue la cause profonde des données non valides.

Générer des source maps
Les source maps sont requises pour l'étape 4 du flux de travail de diagnostic. Générez une source map avec votre outil de build, puis téléchargez-la sur la console ARMS.
Pour télécharger un fichier source map, recherchez votre application sur la page Browser Monitoring, puis choisissez More > Settings dans la colonne Actions. Sur la page des paramètres, cliquez sur l'onglet Advance.
Webpack
Dans webpack.config.js, définissez la propriété devtool sur "source-map". Webpack prend en charge 13 valeurs devtool pour différents types de source maps. "source-map" génère un fichier .map complet et distinct, ce qui est recommandé pour le diagnostic des erreurs en production.
const path = require('path');
module.exports = {
entry: './src/index.js',
output: {
filename: 'bundle.js',
path: path.resolve(__dirname, 'dist')
},
devtool: "source-map"
};
Gulp
Utilisez le package gulp-sourcemaps :
var gulp = require('gulp');
var sourcemaps = require('gulp-sourcemaps');
gulp.task('javascript', function() {
gulp.src('src/**/*.js')
.pipe(sourcemaps.init())
.pipe(sourcemaps.write('../sourcemaps'))
.pipe(gulp.dest('dist'));
});
Grunt
Avec grunt-contrib-uglify uniquement :
grunt.initConfig({
uglify: {
options: {
sourceMap: true
}
}
});
Avec grunt-usemin (qui appelle grunt-contrib-concat et grunt-contrib-uglify) :
grunt.initConfig({
concat: {
options: {
sourceMap: true
}
},
uglify: {
options: {
sourceMap: true,
sourceMapIn: function(uglifySource) {
return uglifySource + '.map';
},
}
}
});
Avec grunt-jsmin-sourcemap :
module.exports = function(grunt) {
grunt.loadNpmTasks('grunt-jsmin-sourcemap');
grunt.initConfig({
'jsmin-sourcemap': {
all: {
src: ['scripts/script.js'],
dest: 'scripts/script.jsmin-grunt.js',
destMap: 'scripts/script.jsmin-grunt.js.map'
}
}
});
grunt.registerTask('default', 'jsmin-sourcemap');
};
Angular CLI
ng build --prod --source-map --vendor-source-map
UglifyJS2
UglifyJS2 est un outil CLI. Pour plus d'options, consultez Options de source map CLI.
uglifyjs app.js -o app.min.js --source-map app.min.js.map
SystemJS
Utilisez SystemJS Builder :
builder.bundle('app.js', 'app-outfile.js', {
minify: true,
sourceMaps: true
});