In create-react-app v2 initialization throws Uncaught ReferenceError: _typeof is not defined

[maciekmp]

Fresh app installation with create react app v2 and mapbox was added as first extra package. After run app in browser all I get in console is:

Uncaught ReferenceError: _typeof is not defined

mapbox-gl-js version: 0.49

browser: Google Chrome

Steps to Trigger Behavior

1. yarn create react-app mapbox-app
2. cd mapbox-app
3. yarn add mapbox-gl
4. Add Mapbox initialization code in componentDidMount
5. yarn start

Expected Behavior

Display functional map container. Work without errors in console.

Actual Behavior

Display only canvas with solid background and get Uncaught ReferenceError: _typeof is not defined in console few times.

[raja]

Same issue.

[mollymerp]

@maciekmp can you please provide a minimal reproduction of the issue you're seeing (for example on JSbin)? that will make it easier for us to diagnose if this is an issue with this library, your implementation, or the third party library.

[ryanhamley]

I'd guess this is related to this issue since create-react-app sets up Babel behind the scenes but it's hard to tell #3422

[boyur]

Hi. I have the same mistake.

react-scripts: 2.0.3
mapbox-gl: 0.49.0,
react: 16.5.2

[raja]

I was able to resolve the issue by ejecting the CRA 2.x app and excluding mapbox-gl from one of the webpack rules. See below:

          // Process any JS outside of the app with Babel.
          // Unlike the application JS, we only compile the standard ES features.
          {
            test: /\.js$/,
            exclude: [/@babel(?:\/|\\{1,2})runtime/, /.*mapbox-gl.*/],
            loader: require.resolve('babel-loader'),
            options: {
              babelrc: false,
              configFile: false,
              compact: false,
              presets: [
                [require.resolve('babel-preset-react-app/dependencies'), { helpers: true }]
              ],
              cacheDirectory: true,
              // Don't waste time on Gzipping the cache
              cacheCompression: false,

              // If an error happens in a package, it's possible to be
              // because it was compiled. Thus, we don't want the browser
              // debugger to show the original code. Instead, the code
              // being evaluated would be much more helpful.
              sourceMaps: false
            }
          },

[willrbc]

@mollymerp
I've created this minimal repo that reproduces this issue. I'd prefer not to eject from CRA just to use this library.

https://github.com/willrbc/mapbox-cra-test

[maciekmp]

Thanks @mollymerp for quick response, it is hard to repro on jsbin because it is connected with how npm package is prepared and how CRA v2 handle npm packages under the mask. I post it here first because I believe it can be fixed with the configuration of the build process for this package.

Even example for @willrbc is quite nice it uses flow, I uploaded my version without it https://github.com/maciekmp/mapbox-cra2

[willrbc]

Even example for @willrbc is quite nice it uses flow, I uploaded my version without it https://github.com/maciekmp/mapbox-cra2

My bad, Flow is not installed in this repo, I just left some type info in there from my main project

[Timer]

Hey! I was looking at dist/mapbox-gl.js and think I see what's going wrong.

dist/mapbox-gl.js declares a few module chunks and relies on the defined function to be converted to a string via Function.toString().
Because the code that's being evaluated elsewhere is first evaluated under the browser's scope, Babel compiles it because it assumes whatever globals it has made available will continue to be available (this is normally a safe assumption).

To solve this, the bundles need to be pre-stringified during build time instead of at run time.
This will prevent Babel from performing any transformations -- fwiw this is exactly how we handle it in react-error-overlay.

[ryanhamley]

This sounds similar to the cause of #4359 which was fixed with #6956. cc @mourner

For what it's worth, @anandthakker seems to have ruled out the idea of inlining workers at build time with this comment

Statically inline the worker code into the final bundle, rather than using Function.prototype.toString() to generate the appropriate code at runtime. This would nearly double the size of the mapbox-gl.js script, by duplicating large portions of the code as a string. I don't think this is an acceptable tradeoff.

[Timer]

I'm not sure I understand what would become "duplicated"... is it because you create multiple workers that each share a chunk?

If that's the case, what about wrapping it in an eval? You could then continue using Function.prototype.toString() to build the chunks but the code will remain uncompiled.
This should achieve the same effect?

[mollymerp]

It looks like this issue was fixed in facebook/create-react-app#5278. Closing because I don't think this is actionable on our end.