Source Maps don't work on Chrome #2145

Closed
bolismauro opened this Issue Mar 6, 2016 · 223 comments

Comments

Projects
None yet
@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 #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

This comment has been minimized.

Show comment
Hide comment
@priyajeet

priyajeet Mar 8, 2016

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

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

@afilp

This comment has been minimized.

Show comment
Hide comment

afilp commented Mar 11, 2016

+1

@iknowcss

This comment has been minimized.

Show comment
Hide comment
@iknowcss

iknowcss 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/

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

This comment has been minimized.

Show comment
Hide comment

+1

@afilp

This comment has been minimized.

Show comment
Hide comment
@afilp

afilp Mar 15, 2016

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

afilp commented Mar 15, 2016

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

@priyajeet

This comment has been minimized.

Show comment
Hide comment

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

@bolismauro

This comment has been minimized.

Show comment
Hide comment
@bolismauro

bolismauro Mar 15, 2016

Yes I have the issue on OSX too.

Yes I have the issue on OSX too.

@MichaelSitter

This comment has been minimized.

Show comment
Hide comment
@MichaelSitter

MichaelSitter 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

+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

This comment has been minimized.

Show comment
Hide comment
@tonyjin

tonyjin Mar 15, 2016

+1 have this issue on OSX

tonyjin commented Mar 15, 2016

+1 have this issue on OSX

@cowboy

This comment has been minimized.

Show comment
Hide comment
@cowboy

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

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

This comment has been minimized.

Show comment
Hide comment

ghost commented Mar 22, 2016

+1 OSX

@marc314

This comment has been minimized.

Show comment
Hide comment
@marc314

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

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

This comment has been minimized.

Show comment
Hide comment
@darioml

darioml 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?

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

This comment has been minimized.

Show comment
Hide comment
@cjquinon

cjquinon Apr 19, 2016

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

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

@joshburgess

This comment has been minimized.

Show comment
Hide comment
@joshburgess

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

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

This comment has been minimized.

Show comment
Hide comment
@jsg2021

jsg2021 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 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

This comment has been minimized.

Show comment
Hide comment
@jsg2021

jsg2021 Apr 25, 2016

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

jsg2021 commented Apr 25, 2016

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

@AnandVishnu

This comment has been minimized.

Show comment
Hide comment
@AnandVishnu

AnandVishnu 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

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

This comment has been minimized.

Show comment
Hide comment
@evisong

evisong 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?

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

This comment has been minimized.

Show comment
Hide comment

+1 OSX

@jsg2021

This comment has been minimized.

Show comment
Hide comment
@jsg2021

jsg2021 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! :)

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! :)

@steida steida referenced this issue in este/este May 16, 2016

Closed

Put back ideal webpack sourcemaps #877

@jowcy

This comment has been minimized.

Show comment
Hide comment
@jowcy

jowcy May 18, 2016

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

jowcy commented May 18, 2016

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

@whyer11

This comment has been minimized.

Show comment
Hide comment

whyer11 commented May 26, 2016

+1 OS X

@alasdaircs

This comment has been minimized.

Show comment
Hide comment
@alasdaircs

alasdaircs Jun 1, 2016

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

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

@xuefengwang

This comment has been minimized.

Show comment
Hide comment
@xuefengwang

xuefengwang Jun 4, 2016

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

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

@jotto

This comment has been minimized.

Show comment
Hide comment
@jotto

jotto 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

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

This comment has been minimized.

Show comment
Hide comment

+1 osx

@andrii-frankiv

This comment has been minimized.

Show comment
Hide comment
@andrii-frankiv

andrii-frankiv Jun 14, 2016

Just faced with the same one, fixed by set devtoolModuleFilenameTemplate: '[absolute-resource-path]' to the output section in config.
osx

Just faced with the same one, fixed by set devtoolModuleFilenameTemplate: '[absolute-resource-path]' to the output section in config.
osx

@JakeCooper

This comment has been minimized.

Show comment
Hide comment
@JakeCooper

JakeCooper Jun 21, 2016

+1 Windows

EDIT: Fixed in canary. Definitely a chrome issue.

JakeCooper commented Jun 21, 2016

+1 Windows

EDIT: Fixed in canary. Definitely a chrome issue.

@ryanmargheriti

This comment has been minimized.

Show comment
Hide comment
@ryanmargheriti

ryanmargheriti Jun 22, 2016

If you are not using canary, use @xuefengwang's suggestion and change source-map to inline-source-map in your webpack config.

If you are not using canary, use @xuefengwang's suggestion and change source-map to inline-source-map in your webpack config.

@Sunkari16

This comment has been minimized.

Show comment
Hide comment
@Sunkari16

Sunkari16 Jun 22, 2016

Had the same issue , fixed by changing source-map to inline-source-map as suggested by @xuefengwang

Had the same issue , fixed by changing source-map to inline-source-map as suggested by @xuefengwang

@blink1073 blink1073 referenced this issue in jupyterlab/jupyterlab Jun 23, 2016

Merged

Use inline source map for now #145

@mgol

This comment has been minimized.

Show comment
Hide comment
@mgol

mgol Jun 24, 2016

I'm still seeing the issue in Canary 53.0.2777.0 on OS X. Changing devtool: '#eval-source-map' to devtool: '#inline-source-map' fixes it for me. So it doesn't look fixed.

mgol commented Jun 24, 2016

I'm still seeing the issue in Canary 53.0.2777.0 on OS X. Changing devtool: '#eval-source-map' to devtool: '#inline-source-map' fixes it for me. So it doesn't look fixed.

@jivewise jivewise referenced this issue in openstax/tutor-js Jun 29, 2016

Closed

Fixing source maps #1141

@zzuligy

This comment has been minimized.

Show comment
Hide comment
@zzuligy

zzuligy Jul 5, 2016

for me, #inline-source-map is also not work.I finaly use devtool: "inline-eval-cheap-source-map",.
and it's work.

zzuligy commented Jul 5, 2016

for me, #inline-source-map is also not work.I finaly use devtool: "inline-eval-cheap-source-map",.
and it's work.

@belfz

This comment has been minimized.

Show comment
Hide comment
@belfz

belfz Jul 8, 2016

devtool: '#inline-source-map' allows me to stop on the breakpoint; however it throws an error while trying to evaluate any variable in devtools' console.

belfz commented Jul 8, 2016

devtool: '#inline-source-map' allows me to stop on the breakpoint; however it throws an error while trying to evaluate any variable in devtools' console.

@TroutZen

This comment has been minimized.

Show comment
Hide comment

+1 OSX

@sokra sokra closed this Aug 24, 2017

@elmariachi111

This comment has been minimized.

Show comment
Hide comment
@elmariachi111

elmariachi111 Aug 24, 2017

After pulling my hair for 2hs I got it working on

webpack: 3.5.5
Javascript ES6
Node: v8.2.1
Chrome: 60.0.3112.101
(symfony encore 0.14)

using devtool: 'cheap-module-eval-source-map'

After pulling my hair for 2hs I got it working on

webpack: 3.5.5
Javascript ES6
Node: v8.2.1
Chrome: 60.0.3112.101
(symfony encore 0.14)

using devtool: 'cheap-module-eval-source-map'

@robophil

This comment has been minimized.

Show comment
Hide comment
@robophil

robophil Aug 25, 2017

Anyone got this to play nicely with vscode chrome debbuger
At this rate, i'll be bald by the end of the day

Anyone got this to play nicely with vscode chrome debbuger
At this rate, i'll be bald by the end of the day

@sherlockwang

This comment has been minimized.

Show comment
Hide comment
@sherlockwang

sherlockwang Aug 28, 2017

inline-source-map only works in Chrome (60.0.3112.113) the first time page loaded. Works well in FireFox and Chrome Canary.

eval-cheap-module-source-map works fine in all three browsers, but disabled adding breakpoints.

I did some further tests, It looks like eval-*** options will always work, but disabled adding breakpoints, while others only works the first time when page loaded in Chrome.

To me, it more likes a Chrome bug, because it is solved in Canary. I would use inline-source-map at this point, and use ALT + R to refresh the dev tool in Chrome to make the source map works.

inline-source-map only works in Chrome (60.0.3112.113) the first time page loaded. Works well in FireFox and Chrome Canary.

eval-cheap-module-source-map works fine in all three browsers, but disabled adding breakpoints.

I did some further tests, It looks like eval-*** options will always work, but disabled adding breakpoints, while others only works the first time when page loaded in Chrome.

To me, it more likes a Chrome bug, because it is solved in Canary. I would use inline-source-map at this point, and use ALT + R to refresh the dev tool in Chrome to make the source map works.

@frandiox frandiox referenced this issue in rollup/rollup Oct 23, 2017

Open

Sourcemaps in DevTools #1685

ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Nov 5, 2017

updated react support
- 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 Nov 5, 2017

updated react support
- 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 Nov 6, 2017

updated react support
- 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 Nov 6, 2017

updated react support
- 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 Nov 6, 2017

updated react support
* 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)
* updated webpack configuration so it can read from a package.json
defined on a plugin

ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Nov 6, 2017

updated react support
* 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)
* updated webpack configuration so it can read from a package.json
defined on a plugin

@ohadlevy ohadlevy referenced this issue in martinpovolny/manageiq-ui-classic Nov 6, 2017

Merged

updated react support #2

@radetok

This comment has been minimized.

Show comment
Hide comment
@radetok

radetok Nov 8, 2017

I am still having issues with this one. What is the status of it?

radetok commented Nov 8, 2017

I am still having issues with this one. What is the status of it?

@oskaremil

This comment has been minimized.

Show comment
Hide comment
@oskaremil

oskaremil Nov 13, 2017

Have this problem too i Chrome.
Works fine in Firefox.

Restarting webpack caused Chrome to update so I suspect it is some error there that Firefox detects and Chrome does not.

Have this problem too i Chrome.
Works fine in Firefox.

Restarting webpack caused Chrome to update so I suspect it is some error there that Firefox detects and Chrome does not.

@chaoyangnz

This comment has been minimized.

Show comment
Hide comment

+1

@csvan

This comment has been minimized.

Show comment
Hide comment
@csvan

csvan Nov 22, 2017

This does not work for me in Chrome 62, regardless of what I set devtool as.

I can verify that the .map files are indeed being generated and have the proper names (they are also properly referenced from the JS files they belong to), but when I try to open the files in DevTools, nothing gets loaded.

It's been a while since I last visited this issue, but I am almost certain it kind of worked for med in Chrome 57.

csvan commented Nov 22, 2017

This does not work for me in Chrome 62, regardless of what I set devtool as.

I can verify that the .map files are indeed being generated and have the proper names (they are also properly referenced from the JS files they belong to), but when I try to open the files in DevTools, nothing gets loaded.

It's been a while since I last visited this issue, but I am almost certain it kind of worked for med in Chrome 57.

@StasGoshtein

This comment has been minimized.

Show comment
Hide comment
@StasGoshtein

StasGoshtein Nov 24, 2017

+1
Chrome 62, High Sierra

+1
Chrome 62, High Sierra

ohadlevy added a commit to ohadlevy/manageiq-ui-classic that referenced this issue Nov 28, 2017

updated react support
- 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 melvincarvalho referenced this issue in linkeddata/rdflib.js Dec 7, 2017

Open

Test failling on node 6 #212

@melvincarvalho

This comment has been minimized.

Show comment
Hide comment
@melvincarvalho

melvincarvalho Dec 7, 2017

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

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

@csvan

This comment has been minimized.

Show comment
Hide comment
@csvan

csvan Dec 7, 2017

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

csvan commented Dec 7, 2017

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

@jakeNiemiec

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

jakeNiemiec 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

@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

This comment has been minimized.

Show comment
Hide comment
@kud

kud 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. :')

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

This comment has been minimized.

Show comment
Hide comment
@aslushnikov

aslushnikov 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 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

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

jakeNiemiec 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)

@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

http://stackoverflow.com/questions/39146381/sourcemaps-are-detected-i…
…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 react support
- 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

This comment has been minimized.

Show comment
Hide comment
@clshortfuse

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

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

This comment has been minimized.

Show comment
Hide comment
@avesus

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

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 react support
- 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 react support
- 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 react support
- 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

devtool: Use cheap-module-inline-source-map
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 react support
- 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

This comment has been minimized.

Show comment
Hide comment
@Slapbox

Slapbox Feb 17, 2018

This is very much still an issue.

Slapbox commented Feb 17, 2018

This is very much still an issue.

@jakeNiemiec

This comment has been minimized.

Show comment
Hide comment
@jakeNiemiec

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

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

This comment has been minimized.

Show comment
Hide comment
@beethoven2493

beethoven2493 Mar 11, 2018

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

#6400

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

#6400

@rbeer

This comment has been minimized.

Show comment
Hide comment
@rbeer

rbeer Apr 14, 2018

@avesus
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.

So it's not just me who thinks webpack is awfully bloated. Good to know. Thanks for saving me all these hours!

rbeer commented Apr 14, 2018

@avesus
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.

So it's not just me who thinks webpack is awfully bloated. Good to know. Thanks for saving me all these hours!

@karlhorky karlhorky referenced this issue in prettier/prettier Jul 19, 2018

Open

Space after function name in declarations #3845

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment