Your reprodution doesn't contain any reference to transpileDepenencies.

You likely forgot to push the changes?

sorry! submitted.

The problem with the arrow function has been solved, because i uesd tnpm, but new problems have arisen, TypeError.

After adding transpileDepenencies, @antv/g6 It doesn't work on chrome.

Workaround: set babel.config.js to:

module.exports = {
  sourceType: 'unambiguous',
  presets: ['@vue/cli-plugin-babel/preset']
};

I think we should set it as the default🤔

I this setting safe for arbitrary dependencies? Afaik it's only necessary when attempting to transpile a module that's using the commonjs module format.

I've been living with sourceType: 'unambiguous' for a year or so. It will break things in various plugins and I don't think it should be the default.

@JessicaSachs could you elaborate on the incompatible plugins?

I’ve run into issues with plugins like styleguidist that do some static analysis. They’ve been fixed, but not until I submitted a reproduction repo. It’s not a common setting and there is risk of breaking existing repositories by changing the sourceType default.

I've been living with sourceType: 'unambiguous' for a year or so. It will break things in various plugins and I don't think it should be the default.

Is there any problem, can you list?

Workaround: set babel.config.js to:

module.exports = {
  sourceType: 'unambiguous',
  presets: ['@vue/cli-plugin-babel/preset']
};

I think we should set it as the default🤔

this can be ok

@JessicaSachs If you mean this issue vue-styleguidist/vue-styleguidist#436, I believe it's not related to the sourceType configuration.

@LinusBorg

According to the babel documentation, unambiguous seems to be a safer option than the default module, especially when dealing with third-party dependencies.

The edge cases are ambiguous modules as listed in https://github.com/tc39/proposal-UnambiguousJavaScriptGrammar#problem

For such a simple and ambiguous file, if no polyfills/helpers are injected:

• With sourceType: 'module', a "use strict" pragma would be added to the top of that file and the whole module will run in strict mode.
• With sourceType: 'unambiguous', it will be considered a CommonJS module and remain as-is.

I think the latter one is more reasonable in the context of third-party dependencies.

The real problem:

If a module references something like Symbol and a polyfill module needs to be added:

• With sourceType: 'module', an import statement will be injected to the file, regardless of the presence of module.exports;
• With sourceType: 'unambiguous', an require statement will be injected if no import/export is seen in the file.

Because we disabled the module transformation in babel, all import/require statements are passed down to webpack as-is. And the former case will encounter an error in webpack runtime because webpack has stricter rules on ES modules (the exports object would be read-only). And that's exactly the case in this issue.

This also means, if we don't change the default sourceType configuration, all third-party CommonJS dependencies with partially transpiled code will encounter similar problems.

These use cases are also described in the README (the 3rd option).
We currently recommend users to set useBuiltIns: 'entry', which is quite unintuitive and also sub-optimal in code size.
So I believe sourceType: 'unambiguous' could be a much better solution.

we could experiment with it in a beta release, maybe?

Plus we can document that babel's overrides option can be used to fine-tune this for individual packages/files if necessary:

module.exports = {
  sourceType: 'unambiguous',
  presets: ['@vue/cli-plugin-babel/preset'],
  overrides: [
    {
       test: 'node_modules/some-package/**/*',
       sourceType: 'module'
    }
  ]
};

Yeah, we can experiment it in v4.1.0-beta.0.