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

Question

Mon problème est simple.

Je veux juste faire VS Code du débogueur de travail avec webpack-dev-serveur sans ignorer mes points d'arrêt.

Maintenant, webpack-dev-serveur sert le lot de fichiers à partir de la mémoire, tandis que, si je comprends bien, le VS débogueur de Code recherche pour eux sur le disque (...ou pas?...)

En conséquence, chaque fois que j'ai mis un point d'arrêt je obtenir le redouté

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

Maintenant, tous liés à la question que j'ai pu trouver a eu à faire avec la machine pour la plupart, et non pas avec le fait que webpack-dev-server sert de la mémoire. Je ne suis pas à l'aide de caractères d'imprimerie. Semble que les gens ne sont pas à l'aide de webpack-dev-serveur, ou il me manque quelque chose de flagrant, avec mon argent sur celui-ci.

C'est mon VS Code 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 ces sont les lignes de mon webpack.config.js

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

J'ai essayé différentes modifications de la launch.json , en vain, donc je suis en train de le coller dans la vanille forme.

Notez que l' output.path est utilisé uniquement lorsqu'il y a une production de construire et les fichiers sont vomies sur le disque.

Voici ce que la structure des fichiers est dans la servi en de la page:

Et voici la commande que j'suis en cours d'exécution dans le développement

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

Enfin, en voici un morceau 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 conduit fou, j'ai passé les 3 dernières heures à récurer les Googles en vain, et actuellement il est 5H du matin.

Mise à JOUR: Malheureusement, depuis la prise de la question, j'ai arrêté de l'utiliser VS Code et sont passés à Webstorm à la place. Merci à tous pour l'aide et pour votre temps.

Answer 1

De mon expérience (environ 15 mins ago), si 'webpack.config.js" a une valeur pour la propriété de contexte, alors que doit être pris en compte pour '.vscode/lancement.json".

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

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

Puis de le lancer.json besoins de ce contexte ('src') trop:

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

Je viens de mettre à jour/fixe mon repo alors maintenant, Tapuscrit de points d'arrêt doivent se lier.

https://github.com/marckassay/VSCodeNewProject

J'espère que ça aide.

Answer 2

Pour Webpack 4:
Installez webpack-cli localement si vous ne l'avez pas déjà installé (il a été tiré hors de la webpack).

Ajouter le suivant VSCode configuration debug pour votre .vscode/launch.json (c'est le fichier qui VSCode s'ouvre lorsque vous cliquez sur l'icône roue en vue de 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 fera débogueur s'arrêter dans la première (inclus) de la ligne de webpack.js, comme ceci:

Answer 3

Vieux fil, mais il revient toujours dans les recherches ...

Il semble que l'activation de "l'écriture du 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
  }
};
 

Answer 4

Si au cas où quelqu'un troublant avec start-server-webpack-plugin de webpack:

Récemment, j'ai bloqué sur le même sujet, et @MarkoBonaci réponse venu à son secours. Cependant, j'ai collé sur une autre erreur qui est produite par le webpack plugin: start-server-webpack-plugin.

Ci-dessous est l'erreur que j'ai eu, quand j'ai lancé par l'application à l'aide du débogueur de vscode:

cd /home/moi/des projets/des villageois-rubriques ; env "NODE_ENV=développement" /home/moi/.nvm/versions/node/v11.6.0/bin/node --inspecter-brk=33538 node_modules/.bin/webpack-cli --couleurs --progress --config ./webpack.dev.js Débogueur à l'é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 Débogueur. nettoyage webpack-plugin: /home/rajeev/projets/villageois-rubriques/dist a été supprimé. 10% de construction 1/1 modules 0 active webpack est à regarder les fichiers...

98% après émettant StartServerPluginStarting l'inspecteur de 127.0.0.1:33538 a échoué: l'adresse est déjà en cours d'utilisation

Comme vous pouvez le voir StartServerPlugin est d'utiliser le même port 33538 ce qui est déjà pris par le processus parent. Nous avons donc besoin de raconter StartServerPlugin utiliser un autre port pour son inspection de l'initialisation. De là, on peut atteindre par le biais de l'initialisation de StartServerPlugin.

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

Ici, en nodeArgs nous sommes en précisant les inspecter port 5858. Après cette configuration est enregistrée puis relancer l'application via le Débogueur de vscode, vous permettra de bien démarrer l'application.