Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source Maps don't work on Chrome #2145

Closed
bolismauro opened this issue Mar 6, 2016 · 225 comments
Closed

Source Maps don't work on Chrome #2145

bolismauro opened this issue Mar 6, 2016 · 225 comments
Assignees
Labels

Comments

@bolismauro
Copy link

@bolismauro bolismauro commented Mar 6, 2016

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 #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.

@bebraw bebraw added the question label Mar 6, 2016
@priyajeet
Copy link

@priyajeet priyajeet commented Mar 8, 2016

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

@afilp
Copy link

@afilp afilp commented Mar 11, 2016

+1

@iknowcss
Copy link

@iknowcss iknowcss commented Mar 15, 2016

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
Copy link

@dsebastien dsebastien commented Mar 15, 2016

+1

@afilp
Copy link

@afilp afilp commented Mar 15, 2016

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

@priyajeet
Copy link

@priyajeet priyajeet commented Mar 15, 2016

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

@bolismauro
Copy link
Author

@bolismauro bolismauro commented Mar 15, 2016

Yes I have the issue on OSX too.

@MichaelSitter
Copy link

@MichaelSitter MichaelSitter commented Mar 15, 2016

+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
Copy link

@tonyjin tonyjin commented Mar 15, 2016

+1 have this issue on OSX

@cowboy
Copy link

@cowboy cowboy commented Mar 18, 2016

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.

@ghost
Copy link

@ghost ghost commented Mar 22, 2016

+1 OSX

@marc314
Copy link

@marc314 marc314 commented Mar 22, 2016

+1 on Windows Chrome 49.0.2623.8.

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

@darioml
Copy link

@darioml darioml commented Apr 15, 2016

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
Copy link

@cjquinon cjquinon commented Apr 19, 2016

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

@joshburgess
Copy link

@joshburgess joshburgess commented Apr 20, 2016

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
Copy link

@jsg2021 jsg2021 commented Apr 21, 2016

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
Copy link

@jsg2021 jsg2021 commented Apr 25, 2016

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

@AnandVishnu
Copy link

@AnandVishnu AnandVishnu commented Apr 27, 2016

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
Copy link

@evisong evisong commented May 13, 2016

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
Copy link

@psr1919plus21 psr1919plus21 commented May 13, 2016

+1 OSX

@jsg2021
Copy link

@jsg2021 jsg2021 commented May 13, 2016

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
Copy link

@jowcy jowcy commented May 18, 2016

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

@whyer11
Copy link

@whyer11 whyer11 commented May 26, 2016

+1 OS X

@alasdaircs
Copy link

@alasdaircs alasdaircs commented Jun 1, 2016

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

@xuefengwang
Copy link

@xuefengwang xuefengwang commented Jun 4, 2016

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

@jotto
Copy link

@jotto jotto commented Jun 7, 2016

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

@idostern
Copy link

@idostern idostern commented Jun 13, 2016

+1 osx

ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Nov 28, 2017
- updated to react 16.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
@melvincarvalho
Copy link

@melvincarvalho melvincarvalho commented Dec 7, 2017

Same issue Version 55.0.2883.87 Built on Ubuntu , running on Ubuntu 16.04 (64-bit)

@csvan
Copy link

@csvan csvan commented Dec 7, 2017

Why is this closed? It is clearly still an issue.

@jakeNiemiec
Copy link

@jakeNiemiec jakeNiemiec commented Dec 7, 2017

@csvan I know how you feel, I still think Chrome devtools is the best available.

My bug report was recently updated to WontFix saying "This is a known issue with webpack; we can't do much" because "Webpack changes the content of the sourcemaps resources"

It would seem that Chrome has indicated that the fault is solely with Webpack, but I feel that a solution would not be that difficult (esp. if a dev was fluent in WDS & chrome devtools internals). //cc @aslushnikov @pavelfeldman

@kud
Copy link

@kud kud commented Dec 7, 2017

Sourcemaps and browsers together are really weird.

For instance, the only sourcemap which works on both browsers (firefox and chrome) is cheap-module-inline-source-map

But this is for webpack itself.

About babel/js now, the sourcemap works also well on both browsers.

However, for css-loader for instance, sourcemap doesn't work at all on firefox but does on chrome.

It's like tennis table here. :')

@aslushnikov
Copy link

@aslushnikov aslushnikov commented Dec 8, 2017

@jakeNiemiec the issue you're pointing to is about the DevTools Workspaces automapping against sourcemapped files. AFAIU it's not related to the issue discussed here, or am I missing something?

@jakeNiemiec
Copy link

@jakeNiemiec jakeNiemiec commented Dec 14, 2017

@aslushnikov I was trying to make the point that the Workspaces 2 chrome feature that was added for everyone in Chrome 63 breaks Webpack sourcemaps. Now it seems that the issue is affecting other webpack devs

It would have been nice to have the option to opt-out of this breaking change.

(I may be wrong, but I believe that Workspaces 2 is the former Persistence 2 experiment)

janory added a commit to janory/tagnsearch that referenced this issue Dec 15, 2017
…n-chrome-but-original-source-is-not-loaded-using-webpa

webpack/webpack#2145
devtool had to be changed to "cheap-module-source-map" since chrome debugger does not work anymore
ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Dec 25, 2017
- updated to react 16.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
@clshortfuse
Copy link

@clshortfuse clshortfuse commented Dec 26, 2017

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
Copy link

@avesus avesus commented Jan 7, 2018

@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!

priley86 added a commit to priley86/manageiq-ui-classic that referenced this issue Jan 21, 2018
- updated to react 16.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Jan 21, 2018
- updated to react 16.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Jan 22, 2018
- updated to react 16.2.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
vperron added a commit to Polyconseil/systematic that referenced this issue Jan 25, 2018
webpack/webpack#2145

That's the only one that actually works, both for breakpoints and test
traces.
ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Jan 25, 2018
- updated to react 16.2.
- created a component mounting helper to initalize react componenets from rails views
- create a component registery, so that plugins can register their top level containers
- broke down generate webpack chunks into plugin specific vs common js code (to avoid duplications of js code within the bundle)
- change webpack source maps to inline so it can easily be used to debug in the browser. (see webpack/webpack#2145)
@Slapbox
Copy link

@Slapbox Slapbox commented Feb 17, 2018

This is very much still an issue.

@jakeNiemiec
Copy link

@jakeNiemiec jakeNiemiec commented Feb 21, 2018

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
Copy link

@beethoven2493 beethoven2493 commented Mar 11, 2018

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

#6400

@wallynm
Copy link

@wallynm wallynm commented Jul 30, 2018

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
Copy link
Member

@pranshuchittora pranshuchittora commented Mar 6, 2020

inline source maps works

@mdrahiem
Copy link

@mdrahiem mdrahiem commented Oct 13, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.