Source Maps don't work on Chrome

[bolismauro]

Hello everyone,
I just started to use webpack and I'm having serious issues in debugging my code.
The problem is that the Chrome debugger doesn't work properly.
I'm not sure if this is a webpack issue, a Chrome issue or my fault.

This is my webpack file

var webpack = require('webpack');

module.exports = {
  entry: [
    './app',
  ],
  output: {
    path: __dirname + '/assets',
    publicPath: '/assets',
    filename: 'app.js',
  },
  devServer: {
    contentBase: __dirname + '/assets',
    host: '0.0.0.0',
    port: process.env.PORT,
    historyApiFallback: true,
    watchOptions: {
      aggregateTimeout: 300,
      poll: 1000,
    }
  },
  cache: true,
  devtool: 'inline-source-map',
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new webpack.DefinePlugin({
      'process.env.NODE_ENV': '"development"',
    }),
  ],
  module: {
    preLoaders: [
    ],
    loaders: [
      {
        test: /\.js$/,
        include: [ __dirname ],
        exclude: /node_modules/,
        loader: 'babel-loader',
      },
    ],
  },
  node: {
    fs: 'empty',
  },
};

By changing the devtool option I get different behaviours:

• eval: the debugger works correctly but the code is really hard to debug because I see the transpiled code
• source-map: When I set a brekpoint in a certain line, chrome often moves that breakpoint in another line. When I use the step over functionality, chrome shows me the wrong line even though the line where I stopped the execution was correct (usually the debugger moves the execution indicator where the function is declared)
• hidden-source-map: same as eval
• inline-source-map: same as source-map
• eval-source-map: The debugger adds the breakpoints on the correct line, but the execution never stops. This seems to be connected to Chrome 40 doesn't recognized source map urls produced with #eval #740
• cheap-source-map: same as eval
• cheap-module-source-map: same as source-map

I've tried to search both Chrome and Webpack related issues, changing browser or anything else it comes in my mind without success.

[priyajeet]

Having this same issue. Could also be related to Babel 6.

[afilp]

+1

[iknowcss]

I'm having this issue too. The interesting thing is that it only happens in Windows. In OS X and Linux the source maps line up correctly. Maybe there is some kind of LF/CRLF issue?

I verified that my source maps generated in windows, linux, and OS X line up correctly using this tool: http://sokra.github.io/source-map-visualization/

[dsebastien]

+1

[afilp]

@iknowcss I am also using my project in Windows, maybe this shows something.

[priyajeet]

I have this issue on OSX.
Also, https://phabricator.babeljs.io/T6842

[bolismauro]

Yes I have the issue on OSX too.

[MichaelSitter]

+1
Just tested a bunch of eval-* options in FF 45 and it works fine. Seeing the same problems as @bolismauro in chrome.
Tested on Chrome48 OSX10.10.5

[tonyjin]

+1 have this issue on OSX

[cowboy]

I'm also having major problems with eval sourcemaps in Chrome 49 on OS X. Sourcemaps appear to work fine in Firefox 44. I'm using babel 6.7.2 and webpack 1.12.14.

[Domusnetwork]

+1 OSX

[marc314]

+1 on Windows Chrome 49.0.2623.8.

using devtool: source-map works for the time being, although much slower for dev.

[darioml]

Seeing this now also. OSX, Chrome 49.0.2623.110.

Swapping to inline-source-map, again at the cost of dev time.

Out of interest, I've seen stack traces on other projects include line numbers from source maps (rather than app.bundle.js:100000:15). Is this something on the source-map side, or a browser add-in?

[cjquinon]

I'm seeing this as well on OS X 14.5.0 using Chrome 50.0.2661.75 (64-bit)

[joshburgess]

Haven't tested all of these options, but running into some of the same issues right now on Windows. 'inline-source-map' allows breakpoints to be hit in Chrome, but 'eval-source-map' doesn't... the breakpoints are never hit. Will do further testing with other options as I get time.

[jsg2021]

I'm on OSX, chrome (dev channel) refuses to load my maps. (console message)

I've created a gist

Here is a repo showing it:
https://github.com/jsg2021/broken-source-maps

[jsg2021]

In my broken-source-maps repo, I believe that I've isolated webpack as the sourcemap problem...

[AnandVishnu]

same here on Windows.
I have done few more testing. source-maps works until and unless they are not minified. When I try to minify by running web pack with -p or using the uglify plugin, I can not set break points at certain line. Its seems there is a mismatch between indexs

[evisong]

My guess: as a result of code modification and HMR, the JS running in browser changed, but in meanwhile, chrome doesn't update the sourcemap, so real code and sourcemap are not in-sync anymore, which results in breakpoints' malfunction. Possible?

[psr1919plus21]

+1 OSX

[jsg2021]

It's the size! Once the source maps get too large chrome is choking. I setup my project to split the node_modules from my own code and the vender chunk still dies, but my chunk's map works! :)

[jowcy]

Seeing this happen on two Windows machines, but not on OS X (weird).

[whyer11]

+1 OS X

[alasdaircs]

There certainly seems to be a problem with Chrome 51. See Chrome Bug 611328.

[xuefengwang]

"#inline-source-map" or "#source-map" made the breakpoint work on OSX Chrome, build/rebuild speed is slower though.

[jotto]

It's fixed (and confirmed working for me) in Canary now https://bugs.chromium.org/p/chromium/issues/detail?id=611328#c21

[idostern]

+1 osx

[clshortfuse]

Just throwing some tips for people on Chrome with issues.

If you have the original files, you don't want to use to include the source code in your source map. Use nosources-source-map so that the source map only includes weak references to files and lines. Then Chrome will map that to your workspace files. If you include sources, then you're essentially telling Chrome to look in webpack://* for the sources instead.

It would be nice if you could remap webpack:// to your project folder, but Chrome removed this functionality. If you are using Visual Studio Code with the popular Chrome debugging plug-in, be sure to create a workspace remapping.

[avesus]

@sokra thinks you don't need to edit your original files in browser:

module source != file content in most cases anyway

Anyway ;-)

#559 (comment)

I don't think that webpack 4 is going to solve any actual problems you need to solve:

• CSS component dependencies with ExtractText plugin without module code inserted for each CSS import (you can ignore it now though).
• Debuggable and editable minified code (I'm really stuck!).
• Stable chunk hashes OOB (luckily, solved by the md5 plugin).

So, this issue is most important one. Why webpack adds 4 newlines and a footer comments to each module even when no loaders are enabled? It's ES8 era, and we no more need Babel.

Luckily, @sokra's comment has an advice on how to solve the problem with "real" file paths to make debugging and editing a smooth experience, as it should be.

By the way, if you use transpilation, from TypeScript, CoffeeScript, etc., keep in mind that your transpiler CAN supply perfectly consumable source map to webpack, so it HAS TO refer to your original TypeScript file instead of the intermediate transpiled one. Which allows to put breakpoints right into your original source code - in devtools - and even edit it right there.

Many stages of very correct source map transformations must happen in order to preserve that smooth developer experience.

Unfortunately, webpack doesn't embrace convention over configuration, and breaks your config file every major release, so all this source map transformation pipeline seems to be broken almost all the time.

For sure, it was working for me 2 years ago allowing to smoothly debug my Babel-transpiled ES2015 sources in Chrome, but now it's the era of disabling all of the transpilation, and things are broken again.

I'm very, super sad and incredibly frustrated that the awesome and pretty fast tool which practically all web developers have to use every day (we just have no other production-ready choice able to solve a lot of problems), is appears to be broken almost all the time.

The amount of time I've spent since the first npm i -D webpack is unacceptable, and much more than the time I actually spent developing web applications.

I think, the webpack team should reconsider their over-engineering priorities with the new CSS modules approach, and focus on webpack@5 to get rid of all configurable plugins to support debuggable and editable minified outputs and CSS imports with extracted text OOB.

IMO. Don't be hard on me. The npm team already had issues with my sarcastic impatience, but I have no idea how to express your opinion otherwise. Note that I'm not offering to "fire" @sokra LOL

Happy 2018!

[Nantris]

This is very much still an issue.

[jakeNiemiec]

This issue design choice was confirmed as intentional by @ChromeDevTools in this thread: https://twitter.com/dan_abramov/status/960324134734573569

There's a lot of talk, but this was the best I could get out of them:

Ah, I see. Yeah, at the moment the explicit mappings are gone from Workspaces 2. I'm hearing a lot of feedback similar to yours, though, and we're exploring our options --- kayce

There's 130 people subscribed to this thread, I think this issue could use a bit more visibility. I really don't like to see Chrome enforcing certain user/dev workflows like this.

[beethoven2493]

There is a workaround in the second post on this thread:

#6400

[wallynm]

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn't acessing the current context.
I'm running with webpack-dev-server and webpack 4

[pranshuchittora]

inline source maps works

[mdrahiem]

Configuring with this devtool: 'inline-module-source-map' into webpack fixed my issues where debugger wasn't acessing the current context.
I'm running with webpack-dev-server and webpack 4

this solution worked for me. Thanks @wallynm