By: Evan Boissonnot
26 octobre 2019
Bien dur de debugger depuis Visual Code, en s’attachant sur notre Chrome déjà lancé !
A force de test, de recherche, nous y sommes arrivés … ou presque ! Voyons ensemble comment réussir à debugger un projet TypeScript / Phaser / Javascript, avec Visual code.
Première étape obligatoire, ajouter une configuration de lancement
Avec votre workspace de créé, vous allez ajouter une configuration json à votre launch.json.
Elle sera spécifique pour, non pas un lancement d’un nouveau Chrome, mais un attachement à un Chrome existant.
Ajoutez donc cette configuration Ă votre launch.json :
{
« name »: « attach phaser game »,
« type »: « chrome »,
« request »: « attach »,
« port »: 6062,
« sourceMaps »: true,
« webRoot »: « ${workspaceFolder} »,
« url »: « http://localhost:8080 »,
// « processId »: « ${command:PickProcess} »,
« address »: « localhost »
}
Seconde étape – Avoir l’extension Debugger for Chrome
Pensez à bien installer dans Visual Code l’extension : Debugger for Chrome.
Cette extension va vous permettre de débugger depuis Visual Code, quand vous lancerez une application dans Chrome.
Premier hic : ce n’est pas juste Chrome, mais Chrome customizé
En fait, quand on lance Chrome normalement, il n’est pas prêt pour être debuggué à distance.
Vous devez créer un raccourci spécifique qui va appeler Chrome, avec un paramètre spécifique : le port de debug.
« C:\Program Files (x86)\Google\Chrome\Application\chrome.exe » –remote-debugging-port=6063
Ce port, vous l’aurez remarqué, c’est le même qui est précisé dans la configuration de lancement (le paramètre port).
{
« name »: « attach phaser game »,
« type »: « chrome »,
« request »: « attach »,
« port »: 6062,
« sourceMaps »: true,
« webRoot »: « ${workspaceFolder} »,
« url »: « http://localhost:8080 »,
// « processId »: « ${command:PickProcess} »,
« address »: « localhost »
}
Second hic : il faut le customizer encore plus
Or, même avec ce raccourci spécifique, ou même en le lançant depuis une commande dos :
nous n’arrivons pas à nous attacher à notre chrome. On récupère l’erreur :
ERR_CONNECTION_REFUSED, ou bien
Connexion impossible au processus de runtime. Expiration du dĂ©lai après 10000 ms – (raison : Connexion impossible Ă la cible : connect ECONNREFUSED)
Comment faire ?
En fait, quand on lance Chrome il a déjà un profil d’enregistré (dans un dossier de cache, sur votre pc). Vous devez en préciser un nouveau.
Nous obtenons un raccourci de Chrome qui va lancer Chrome en mode remote debug, avec un profil data dédié :
« C:\Program Files (x86)\Google\Chrome\Application\chrome.exe » –remote-debugging-port=6062 –user-data-dir= »%appdata%\Google\Chrome\itest
Nous avons réussi .. ou presque à debugger depuis VS Code
Une fois toutes ces étapes de réalisées, nous arrivons bien :
- A lancer notre Chrome (le raccourci)
- A lancer notre application sur l’url : http://localhost:8080
- A nous attacher Ă ce Chrome depuis Visual Code
Â
C’est une réussite … non ?! 
Et bien pas totalement en fait. C’est bien beau d’être attaché, si on ne peut pas faire du pas à pas … ça ne sert à rien, n’est-ce pas ?
En analysant les messages d’erreurs depuis Visual Code, nous détectons celui-ci :
Breakpoint ignored because generated code not found (source map problem?).
Tiens, tiens, et si nos sourceMap n’étaient pas trouvés ….? Pourtant nous avons bien précisé dans la configuration : “sourceMaps: true”.
Peut-ĂŞtre lui dire oĂą sont nos sourceMaps (les source map nous permettent de debugger des fichiers TypeScript depuis Chrome, pour rappel) ?
{
« name »: « attach phaser game »,
« type »: « chrome »,
« request »: « attach »,
« port »: 6062,
« sourceMaps »: true,
« webRoot »: « ${workspaceFolder} »,
« url »: « http://localhost:8080 »,
// « processId »: « ${command:PickProcess} »,
« address »: « localhost »,
« sourceMapPathOverrides »: {
« * »: « ${webRoot}/* »
}
}
Et voilà , plus d’erreurs ! Et le debug est opérationnel !
