Adam Zielinski
Adam Zielinski

Reputation: 2874

How to efficiently debug webpack applications?

I am trying to adopt webpack dev server in my project. I know it's quite widely adopted, so it surprised me that debugging the application seems to be quite hard. Since webpack by default produces a single giant bundle, source maps are a must. I have a big problem with them:

Depending on devtool mode, source maps are either slow to parse (eval) or not used to map some stack traces (eval-source-map), e.g there are times the entire stack trace looks like this:
at eval (eval at <anonymous> http://localhost:8082/js/app.js:2004:2), <anonymous>:43:67).
Also, when you manually call console.trace or console.error the output is not mapped. So you have to use tools like sourcemapped-stacktrace - this is both slow, and error-prone.

Currently I use require.js for development because it allows me to debug the application very easily - each and every stack trace points to the correct file and line.

How do I achieve the same result with webpack?

EDIT:
Related issue in google chrome: https://code.google.com/p/chromium/issues/detail?id=376409

Related issue in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=583083

Upvotes: 5

Views: 3898

Answers (2)

Cymen
Cymen

Reputation: 14429

I have found it useful to add an npm run watch task that kicks off webpack like so:

webpack -w --devtool eval

This results in source maps that at least have the correct module name. It is somewhat confusing though as the source mapped source is pre-some sort of processing (babel)? So you'll see in the source something like:

import react from 'react';

But the actual variable name will be munged to something like _react2 or similar. I'd love for the mapped source to be the processed version with the ugly variable names or for the scope to have the definitions as seen in the mapped source.

The actual line I have in my package.json for the above task is:

  "scripts": {
    // other lines edited out
    "watch": "node ./node_modules/webpack/bin/webpack.js -w --devtool eval"
  }

Upvotes: 1

shados
shados

Reputation: 137

Which devtools do you use? Millage may vary, but Chrome (and IE/Edge, yes...IE and Edge) tend to handle sourcemaps the best. While at this point all the major browsers support them, I've had the worse experience with Firefox.

We have very very large bundles and sourcemaps have not caused any slowness in devtools. Which mode are you using? For webpack, using "eval" will do an inline sourcemap that maps files, but not source (so you see the generated code, but 1:1 correlation with the original files). Since a lot of ES6, Typescript and Coffeescript constructs don't map well (eg: generators or comprehensions), this is usually the easiest mode to use, and is also the fastest. Using eval alsoensure it "just works" in Chrome devtools without any action from the developer (your files will be under the webpack:// pseudo-folder)

For the stack trace, I don't know if it is browser specific or what. We use Mocha for unit test, which doesn't look like it's doing anything special for sourcemaps, and it captures stack traces to render them on the test runner's webpack properly (it even includes the webpack:// prefix along with the original file name and proper line number), so maybe the need for that library is browser specific or outdated?

Upvotes: 2

Related Questions