web-dev-qa-db-fra.com

Comment utiliser le débogueur de code VS avec webpack-dev-server (points d'arrêt ignorés)

Mon problème est simple.

Je veux juste que le débogueur de VS Code fonctionne avec webpack-dev-server sans ignorer mes points d'arrêt.

Maintenant, webpack-dev-server sert les fichiers groupés à partir de la mémoire, alors que, si je comprends bien, le débogueur de code VS les recherche sur le disque (... ou pas? ...)

En conséquence, chaque fois que je définis un point d'arrêt, je reçois le redouté

Breakpoint ignored because generated code not found (source map problem?)

Maintenant, toutes les questions que je pouvais trouver concernaient principalement TypeScript, et non pas le fait que webpack-dev-server sert de mémoire. Je n'utilise pas TypeScript. On dirait que les gens n'utilisent pas webpack-dev-server ou que je manque quelque chose de flagrant, avec mon argent sur ce dernier.

Ceci est mon code VS launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.Microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Launch Chrome against localhost",
      "url": "http://localhost:8080",
      "webRoot": "${workspaceRoot}",
      "sourceMaps": true,
      "trace": true
    }
  ]
}

et ce sont les lignes connexes de mon webpack.config.js

  devtool: 'cheap-module-source-map',
  output: {
    path: path.join(__dirname, 'dist'),
    filename: '[name].[chunkhash].js'
  },

J'ai essayé diverses modifications à la launch.json en vain, je ne fais que le coller sous forme vanille.

Notez que le output.path n'est utilisé que lorsqu'il existe une version de production et que les fichiers sont pulvérisés sur le disque.

Voici quelle est la structure des fichiers dans la page servie:

enter image description here

Et voici la commande que je lance en développement

  "scripts": {
    "start": "webpack-dev-server --Host 0.0.0.0 --config ./webpack.config.js"
  },

Enfin, voici un morceau pertinent du fichier de trace

From target: {"method":"Debugger.scriptParsed","params":{"scriptId":"30","url":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js","startLine":0,"startColumn":0,"endLine":150,"endColumn":57,"executionContextId":2,"hash":"216099518F33D6091EC12795265804FB35669A30","executionContextAuxData":{"isDefault":true,"frameId":"18228.1"},"isLiveEdit":false,"sourceMapURL":"manifest.0ec68ebd5f0abf9b4cd4.js.map","hasSourceURL":false,"isModule":false,"length":5906}}
Paths.scriptParsed: could not resolve http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js to a file under webRoot: e:\Mitch\Workspace\Projects\project-name. It may be external or served directly from the server's memory (and that's OK).
SourceMaps.getMapForGeneratedPath: Finding SourceMap for http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js by URI: manifest.0ec68ebd5f0abf9b4cd4.js.map and webRoot: e:\Mitch\Workspace\Projects\project-name
SourceMaps.loadSourceMapContents: Downloading sourcemap file from http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js.map
To client: {"seq":0,"type":"event","event":"script","body":{"reason":"new","script":{"id":1,"source":{"name":"manifest.0ec68ebd5f0abf9b4cd4.js","path":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js","sourceReference":1001}}}}
To client: {"seq":0,"type":"event","event":"scriptLoaded","body":{"path":"http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js"}}
SourceMap: creating for http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js
SourceMap: sourceRoot: 
SourceMap: sources: ["webpack:///webpack/bootstrap 7617f9bf7c8b0bc95159"]
SourceMap: webRoot: e:\Mitch\Workspace\Projects\project-name
SourceMap: no sourceRoot specified, using webRoot + script path dirname: e:\Mitch\Workspace\Projects\project-name\
SourceMap: mapping webpack:///webpack/bootstrap 7617f9bf7c8b0bc95159 => webpack\bootstrap 7617f9bf7c8b0bc95159, via sourceMapPathOverrides entry - "webpack:///*": "*"
SourceMaps.scriptParsed: http://localhost:8080/manifest.0ec68ebd5f0abf9b4cd4.js was just loaded and has mapped sources: ["webpack\\bootstrap 7617f9bf7c8b0bc95159"]

Cela me rend fou, j'ai passé les 3 dernières heures à récurer les google sans succès et il est actuellement 5 heures.

[~ # ~] update [~ # ~] : Malheureusement, depuis que j'ai posé la question, j'ai arrêté d'utiliser VS Code et suis passé à Webstorm. Merci à tous pour l'aide et pour votre temps.

jsondebuggingwebpackvisual-studio-codewebpack-dev-server
28
Dimitris Karagiannis

D'après mon expérience (il y a environ 15 minutes), si "webpack.config.js" a une valeur pour la propriété de contexte, il doit être comptabilisé pour ".vscode/launch.json".

Par exemple, si 'webpack.config.js' a:

module.exports = {
  context: path.resolve(__dirname, 'src'),
  entry: './index.ts',

Ensuite, launch.json a également besoin de ce contexte ('src'):

"url": "http://localhost:8080/",
"webRoot": "${workspaceRoot}/src",
"sourceMaps": true,

Je viens de mettre à jour/corriger mon référentiel alors maintenant, les points d'arrêt TypeScript doivent être liés.

https://github.com/marckassay/VSCodeNewProject

J'espère que ça aide.

16
marckassay

Pour Webpack 4:
Installer webpack-cli localement si vous ne l’avez pas déjà installé (il a été extrait de webpack).

Ajoutez la configuration de débogage VSCode suivante à votre .vscode/launch.json (c'est le fichier que VSCode ouvre lorsque vous cliquez sur l'icône de la roue en mode débogage):

{
  "type": "node",
  "request": "launch",
  "name": "build",
  "program": "${workspaceFolder}/node_modules/.bin/webpack-cli",
  "args": [
    "--config",
    "webpack.config.prod.js"
  ],
  "autoAttachChildProcesses": true,
  "stopOnEntry": true
}

stopOnEntry arrêtera le débogueur dans la toute première ligne (Shebang) de webpack.js, comme ça:

VSCode debugger stops without any breakpoints

6
Marko Bonaci

Vieux fil, mais ça revient quand même dans les recherches ...

C'est comme si vous vouliez "écrire le code généré sur le disque" pourrait être la solution ici: Selon https://webpack.js.org/configuration/dev-server/#devserverwritetodisk- , ajoutez ceci à webpack.config.js:

module.exports = {
  //...
  devServer: {
    writeToDisk: true
  }
};
2
Gyuri

Si au cas où quelqu'un troublait avec start-server-webpack-plugin du webpack:

Je suis récemment resté sur le même problème et réponse de @ MarkoBonaci est venu à la rescousse. Cependant, je suis resté bloqué sur une autre erreur qui est produite par le plugin webpack: start-server-webpack-plugin.

Ci-dessous est l'erreur que j'ai eu, lorsque j'ai lancé par application via le débogueur de vscode:

cd/home/moi/projets/villageois-sujets; env "NODE_ENV = development" /home/me/.nvm/versions/node/v11.6.0/bin/node --inspect-brk = 33538 modules_noeud/.bin/webpack-cli --colors --progress --config. /webpack.dev.js Le débogueur écoute sur ws: //127.0.0.1: 33538/d8bb6d64-a1a1-466e-9501-6313a3dc8bcf Pour obtenir de l'aide, voir: https://nodejs.org/en/docs/inspector Debugger attaché. clean-webpack-plugin:/home/rajeev/projets/village-themes/dist a été supprimé. 10% construisant 1/1 modules 0 webpack actif regarde les fichiers…

98% après avoir émis l'inspecteur StartServerPluginStarting le 127.0.0.1:33538 ont échoué: adresse déjà utilisée

Comme vous pouvez le constater, StartServerPlugin utilise le même port 33538 qui est déjà pris par le processus parent. Nous devons donc dire à StartServerPlugin d’utiliser un autre port pour son initialisation d’inspection. Ceci, nous pouvons y parvenir grâce à l’initialisation de StartServerPlugin.

new StartServerPlugin({
  name: 'server.js',
  nodeArgs: ['--inspect=5858'], // allow debugging),
})

Ici, dans nodeArgs, nous spécifions le port d’inspection comme 5858. Une fois cette configuration enregistrée, puis relancez l'application via le débogueur de vscode, vous pourrez démarrer l'application avec succès.

0
Rajeev K Tomy