Build fails when using mapbox-gl webpack 2 and UglifyJSPlugin

[henningko]

mapbox-gl-js version:
0.32.1

Steps to Trigger Behavior

Set up Mapbox with webpack 2 via vuejs-template

Configuration is as follows:
Base:
https://gist.github.com/henningko/5a76d12a14e485bfc4dd62c2e50ad08e
Production:
https://gist.github.com/henningko/3387f41a55558af60205ea00bbc6b530

Mapbox is used with import mapboxgl from 'mapbox-gl'.

Expected Behavior

Mapbox can be successfully uglified.

Actual Behavior

When building for production, UglifyJS2 has Mapbox throw a Uncaught ReferenceError: n is not defined.
This error also occurs when using Google Closure instead of UglifyJS.
May be related to #1649 , which mainly treats webpack v1 and is closed.

Thanks for your help!

[stevewillard]

Seeing this as well. Anyone know which version I can downgrade to, which minifies properly?

[henningko]

Fixed the problem by setting devtool: 'eval' instead of source-map. Not sure why source-map causes trouble for Mapbox, though.

[mourner]

Could this be a WebPack 2 bug? This doesn't seem to be a fault on the GL JS side.

[stevewillard]

@mourner yeah definitely. The weird thing is that this was working about a month ago for me. I'm trying to narrow down which dependency is causing the issue.

@henningko eval works for me too, but what about production? cheap-module-source-map has the same issue

[henningko]

@stevewillard I was just happy to get a minified version out. 😐 I have opened an issue with webpack, too. It's still a gnarly workaround to get them to function together.

[kachkaev]

Having this in production build since the end of last week, after upgrading mapbox-gl and its react wrapper. Could you please share your workaround guys?

PS: Could not find any mentioning of this error message outside the context of mapbox-gl-js.

[foundryspatial-duncan]

For what it's worth, I built an app about a month ago with mapbox-gl 0.32.1 and webpack 2.2.0 and it built correctly. I just started an almost-identical project with mapbox-gl 0.33.0 and webpack 2.2.1 and I'm having the same problem described above. (Although in my case it says Uncaught ReferenceError: e is not defined. instead of n. This configuration does build if I completely disable the UglifyJsPlugin.

I tried moving mapbox-gl to its own un-minified chunk (didn't work, more problems from Webpack), but that seems like it could fix the problem. The "dist" code in the npm package is minified anyway, so I'd like to tell the uglifier to leave it alone...

[foundryspatial-duncan]

With the version numbers mentioned above, it does build properly if you add the option to not optimize comparisons:

        new webpack.optimize.UglifyJsPlugin({
            sourceMap: true,
            compress: {
                warnings: false,
                comparisons: false,  // don't optimize comparisons
            },
        }),

So, it's something in that Uglify function that's wrecking Mapbox.

[mourner]

@foundryspatial-duncan thank you for finding the potential source of the issue!

Looks like it should be fixed upstream and there's probably nothing we can do on the GL JS side, so I'm closing the issue for now. If you submit related reports in the relevant repos, please link them here to track resolution progress!

[zezhipeng]

module: {
     ...
     noParse: /(mapbox-gl)\.js$/,
     ...
}

just add this in webpack, will be ok

[shotor]

@zezhipeng solution works for me.

Not a 100% sure what it does though. Does this mean mapbox-gl is not minified?

[foundryspatial-duncan]

I've been importing MapboxGL not using the default entrypoint, but rather:

import mapboxgl from 'mapbox-gl/dist/mapbox-gl';

It says (said?) to do that somewhere in the documentation. I remember trying noParse with the dist version and I don't think I had any luck with it.

edit: I guess that's not the practice with the most recent versions of mapbox-gl. If you just import from mapbox-gl as mentioned above, then the noParse solution does work :)

[mikkelsjolin]

This also happens when running meteor --production with Meteor version 1.4.4.
https://blog.meteor.com/announcing-meteor-1-4-4-11027f33e3bf