require appears to not work with useBuiltIns: usage

[weaverryan]

See webpack/webpack#4039 (comment)

Found this when starting a tutorial, where I first show require and module.exports being used. Error is:

get_nice_message.js:1 Uncaught TypeError: Cannot assign to read only property 'exports' of object '#'

This normally happens if you mix require & import/export. But, that's not happening in this case. I haven't checked into the issue much yet...

[Lyrkan]

Hey Ryan,

Just writing here what I already told you on Slack in case it helps other people :)

So, it's not only related to the usage but to useBuiltIns itself (it would happen with the entry value too if you tried to import @babel/polyfill/core-js).

The issue is caused by how polyfills with @babel/preset-env work:

• when using useBuiltIns: 'entry', it will replace your imports of core-js by individual polyfills (to avoid importing the whole lib)
• when using useBuiltIns: 'usage', it will automatically import polyfills where they are needed

As you said, you're not supposed to use both require(...) and import ... at the same time, so to import these polyfills @babel/preset-env has to choose which one of the two it should use.

For that it uses the sourceType option of Babel which can take 3 different values:

• module (default): This means that your files should be using the import ... syntax, which results in @babel/preset-env also using that syntax
• script: This is basically the opposite, and will result in @babel/preset-env using require(...)
• unambiguous: This lets Babel determine which one of module or script it should use based on whether or not your files contain import/export statements

Since module is the default choice (and that we don't override it), @babel/preset-env will use the import ... syntax and cause your files to indirectly have those imports beside require(...) calls.

This is a bit annoying for us since we can't possibly know which one of the two syntaxes people will want to use... so maybe unambiguous would be the right default value in our case (even though it is not 100% accurate).

For now is you encounter this issue you can probably solve it by either disabling polyfills or using:

Encore.configureBabel(
  options => { options.sourceType = 'unambiguous'; },
  { /* ... */ }
);

Also note that if you have some kind of transpiling step (for instance if you are using TypeScript), sourceType will have to be set in accordance to the output of the transpiler (for instance if you are using the import ... syntax but it emits require(...) calls, you'll have to use script or unambiguous).

[weaverryan]

This is a GREAT description of the problem, as usual. THANK you @Lyrkan.

It seems like using unambiguous is probably worth trying. If it doesn't work, we can remove it, and update the recipe to not automatically enable useBuiltIns at all