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.

[Timer]

This issue shouldn't be closed, it's still a problem and will continue to break in odd ways. This should be fixed "once and for all" by this project.

It'd be great to leave this open and brainstorm solutions, e.g. the eval solution proposed above.

[mollymerp]

I believe the code duplication would come from the fact that our worker and main threads share quite a bit of code. Unfortunately, we can't use unsafe eval in this project. We removed the CSP requirement in #5665 for security compliance reasons. We can continue to brainstorm on this thread but right now it isn't actionable for us due to the constraints I've mentioned above.

[ryanhamley]

For what it's worth, I created a minimal test app just now and couldn't reproduce this particular bug so it seems like the fix @mollymerp mentioned helped out here. I'd argue that any further discussion is beyond the scope of this fairly limited bug report and should occur in a new issue created for that purpose, which would make tracking the discussion easier.

That being said, I'm not sure there's a lot of options here. It seems to come down to a choice for us to either greatly increase our bundle size or adopt eval (which isn't really an option as Molly noted). However, we're always trying to improve the library and make it more user-friendly, so we're all ears for suggestions and I will certainly keep thinking about it as well.

[cyrilchapon]

This is still an issue using

• mapbox-gl 0.53.1
• react-map-gl 4.1.1
• parcel-bundler 1.12.3

Getting

Uncaught ReferenceError: _typeof is not defined

From webworker

[joshhoegen]

@cyrilchapon, did you ever find a solution?

To everyone else:
I use this lib everywhere, but I'm only getting this issue in one project that uses Storybook & Lerna. The issue only occurs when using Storybook. Anybody else come across this?

• "@babel/core": "^7.8.4"
• "webpack": "^4.30.0"
• "@storybook/vue": "^5.3.14"
• "mapbox-gl": "^1.8.0"

I have tried all the suggestions in this and related threads to no avail. Fortunately we only use the Storybook internally. The component works in our projects, but it's a pain to npm link it to another project when being worked on.