[0.4.6] Incorrect lines when used with babel-loader (options.sourceMap)

[gabaum10]

Webpack: 3.5.3
uglifyjs: webpack-plugin: 0.4.6
babel-core: 6.25.0
babel-loader: 7.1.1

webpack.config.js:

module.exports = function(env){
   return {
       devtool: 'source-map',
       entry: {...entries...},
       output: {
            path: path.resolve(__dirname, "./client/dist"),
            filename: "[name].entry.js",
            chunkFilename: '[name].chunk.js',
            publicPath: "/static/dist/",
        },
        module: {
            loaders: [
                {
                    test: /\.js$/,
                    exclude: /(node_modules|bower_components)/,
                    use: {
                        loader: 'babel-loader',
                        query: {
                            retainLines: true
                        }
                    }
                },
                {
                    test: /\.woff(2)?(\?([a-z0-9]+|v=[0-9]\.[0-9]\.[0-9]))?$/,
                    loader: "url-loader?limit=10000&mimetype=application/font-woff"
                },
                {test: /\.(jpe?g|ttf|eot|svg|png|gif|cur)(\?([a-z0-9]+|v=[0-9]\.[0-9]\.[0-9]))?$/, loader: "file-loader"},
                {test: /\.html$/, loader: "raw-loader"},
                {test: /\.json$/, use: 'json-loader'},
                {
                    test: /\.css$/,
                    use: ExtractTextPlugin.extract({
                        fallback: "style-loader",
                        use:  {
                            loader: "css-loader",
                            options: {
                                sourceMap: true
                            }
                        }
                    })
                }
            ]
        },
        plugins: [
              new webpack.optimize.UglifyJsPlugin({
            sourceMap: true,
            test: [
                /\.js$/i,
                /\home.entry.js$/i
            ],
            comments: false
        }), 
        new webpack.optimize.CommonsChunkPlugin({
                name: "webpack.common",
                filename: "./webpack.common.js",
                minChunks: 40
            }),
         new ExtractTextPlugin({
                filename: "[name].styles.css",
                ignoreOrder: true,
                allChunks: true
            })
       ]
   }
}

Notice this screenshot from the chrome debugger. There are lines that should quite obviously be able to be debuggable that you can't set breakpoints on. This is from the sourcemap for the file.

Using that combination of tools, my source maps lines are completely out of whack. I can't set breakpoints where I obviously should be able to, and errors are being reported at completely wrong line numbers. If I remove either the uglify plugin or the babel loader, the source maps are rendered correctly. I figured I would start with this plugin before moving on.

I'm at my wits end here. Is this a known issue?

[alexander-akait]

@gabaum10 we get source map from uglify-js in 0.4.6 and seems your get invalid source map from this module, can your try beta version of plugin, just confirm error in new version? Also if your create minimum test repo, it is be easy to investigate problem. Thanks!

[gabaum10]

@evilebottnawi I'm having a hard time installing the beta. When I add it via npm directly from the git+https://github.com/webpack-contrib/uglifyjs-webpack-plugin.git#v1.0.0-beta.2, it's just adding a folder in the node_modules directory with nothing I can reference and am getting the following error:

Error: Cannot find module 'uglifyjs-webpack-plugin'
    at Function.Module._resolveFilename (module.js:489:15)
    at Function.Module._load (module.js:439:25)
    at Module.require (module.js:517:17)
    at require (internal/module.js:11:18)
    at Object.<anonymous> (D:\GWS\soschat\webpack.config.js:10:24)
    at Module._compile (module.js:573:30)
    at Object.Module._extensions..js (module.js:584:10)
    at Module.load (module.js:507:32)
    at tryModuleLoad (module.js:470:12)
    at Function.Module._load (module.js:462:3)

It doesn't seem to generate a /dist/ directory with the index.js file. Do I need to manually run a build before it's usable in my webpack config?

[alexander-akait]

@gabaum10 npm i -D uglifyjs-webpack-plugin@beta

[gabaum10]

Thanks! I just confirmed the issue is still happening with the beta version. I'll make a test repo now and see if I can reproduce it in a simple test case.

[alexander-akait]

@gabaum10 great!

[gabaum10]

@evilebottnawi So I tried to create a simple project with approximately the same configuration as our main web project, but the maps seem to work correctly here.

https://github.com/gabaum10/webpack-uglifyjs-sourcemap-test

Obviously our main project is many orders of magnitude more complex. Is there anything that we could be doing that might make the line numbers get thrown off? Maybe importing something incorrectly? We are trying to migrate our old style RequireJS implementation to use es6 imports and commonJS requires. We mostly use es6 imports, but a few requires mixed in where developers were not diligent. Could the mixing and matching be the problem? I tried to simulate that in my test repo, but it didn't seem to impact it.

I can't believe that this hasn't been an issue anywhere before. Should I perhaps take this to Stackoverflow?

[gabaum10]

Holy crap. There was something with webpack@3.5.3 that was causing the issue. I updated to 3.5.5, the latest and everything just started magically working. Yeesh.

So if anyone has this problem, update to 3.5.5 for the next 3 days before that becomes outdated. :)

[gabaum10]

Crap, scratch that. I had the plugin disabled. Man, my brain is really fizzling...

[alexander-akait]

@gabaum10 tomorrow i investigate this, tired, thanks!

[gabaum10]

I have a theory that I have been mulling over. In our main web project we have a good number of circular dependencies. I have disabled the circular dependency plugin because I wasn't seeing any runtime errors. Perhaps that might be causing the issues I'm seeing? I'll will try to resolve the circular dep tomorrow and report back if that helped.

Is there a precedence for that causing issues while using uglify?

[kzc]

There's no bug here. Better minification negatively impacts debugability. As statements are combined, reordered, folded and removed it stands to reason that many breakpoints will no longer work in the debugger.

If you're willing to accept a few percent larger minified code size just set the uglify options:

compress: false,
mangle: true, 

you'll get the results you seek.

See:

mishoo/UglifyJS#2213 (comment)
https://github.com/mishoo/UglifyJS2#uglify-fast-minify-mode

[kzc]

I just used the debugger in FireFox for the first time in ages (FF55) and I'm happy to report it can step through fully uglified code (compress + mangle) with source maps - unlike Chrome 60. Firefox has a superior debugging experience. Chrome has to pick up their game.

[gabaum10]

I'll try that in a bit and it all might be well and good, but we can't exactly tell people to use Firefox so we can get proper error logs. This goes beyond debuggability but actually limits how useful stack traces are.

[alexander-akait]

@gabaum10 just confirm: comments @kzc help to solve problem? seems it is out of scope uglifyjs-webpack-plugin

[gabaum10]

Unfortunately, that doesn't seem to have helped. The line numbers are still messed up.

@kzc just to confirm, I initialized the plugin like so:

      new UglifyJSPlugin({
            sourceMap: true,
            uglifyOptions: {
                mangle: true,
                compress: false
            }
        })

That seems to spit out mangled, uncompressed code, I think.

Back to my theory, could circular deps potentially cause these issues?

[alexander-akait]

@gabaum10 Maybe 😄 Test repo contain problem?

[kzc]

My source map comments above were just about uglify itself.

Webpack appears to have longstanding issues with source maps on Chrome:

webpack/webpack#3165

[gabaum10]

Well, the source maps work perfectly fine when I turn the uglify plugin off. I don't think it's directly because of chrome and sourcemaps. I've resolved my circular deps and things still seem wonky, so that rules out that theory...

[jpgilchrist]

Could this be an issue with dead code? I had a theory that it might be the case as we have a very large codebase with a bunch of legacy code littered throughout and probably have a bunch of dead code.

The experiment:

I found an entry point with very little dependencies and bundled that alone. The source maps were seemingly perfect. I then added a massive dead code block and then tried the source maps and set a bunch of breakpoints in the dead code block and it somehow broke on the breakpoints I set. See image below:

Those lines never should have been hit.

[gabaum10]

Ok, quick update.

@jpgilchrist may be on to something. I setup eslint for our project and starred the ever so enjoyable process of fixing all 200k issues. Some of these issues were none other than dead code. After finishing about 70%, I ran the production build with uglify and am happy to report an almost perfect source map. Let me finish up fixing all those issues and I will report back and close this issue as needed. I really think the line number discrepancy was because of the dead code in all our terrible legacy code.

[gabaum10]

Great news, after cleaning up all our code, the source map lines are now perfectly aligned! Phew, that was an adventure, but I hope this finding helps someone in the future.

[alexander-akait]

@gabaum10 Congratulations!

[jpgilchrist]

@evilebottnawi but that seems like it's a pretty significant issue. Webpack touts its ability to perform tree shaking. The fact that the existence of dead code causes issues in the generation of source maps is rather disconcerting. With webpack it's relatively common practice to specify something like

if (SOMETHING_DEFINED_BY_DEFINE_PLUGIN) {
 doSomething();
}

If that SOMETHING_DEFINED_BY_DEFINE_PLUGIN evaluates to false then dead code was just introduced, which according to the findings in this issue would be the direct cause of sourceMaps to have invalid line numbers.

Is this a webpack issue, an uglifyjs issue, or is it an uglifyjs-webpack-plugin issue?

@gabaum10 I'm not sure this should be closed quite yet.

[alexander-akait]

@jpgilchrist need investigate this, maybe related webpack/webpack#2145 or webpack/webpack#3165, or maybe problem(s) inside uglify-es. Feel free to reopen. I glad if your help me with this, also if problem(s) in uglifyjs-webpack-plugin PR welcome 👍

[gabaum10]

Alright, well let's investigate further then.

[xiachaoxulu]

it is not a issue on uglifyjs-webpack-plugin.

[xiachaoxulu]

here is a demo. maybe webpack sourcemap mix bug
https://github.com/xiachaoxulu/sourceMapDemo

[alexander-akait]

@xiachaoxulu do you create issue in webpack repo?

[xiachaoxulu]

yes. but it maybe babel-loader's issue. i am crazy

[gabaum10]

@xiachaoxulu can you link the issue you made in the webpack repo here?