Vue-cli: @vue/cli 4.0.5 transpileDependencies invalid

[ghost]

Version

4.0.5

Reproduction link

https://github.com/lxfu/vue-g6

Environment info

Mac、IE11

Steps to reproduce

npm i
npm run serve

What is expected?

app should work under IE11.

What is actually happening?

The arrow function inside the dependency is not compiled

---

IE11 does not support arrow functions

[LinusBorg]

Your reprodution doesn't contain any reference to transpileDepenencies.

You likely forgot to push the changes?

[ghost]

sorry! submitted.

[ghost]

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

[ghost]

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

[sodatea]

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🤔

[LinusBorg]

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.

[JessicaSachs]

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.

[sodatea]

@JessicaSachs could you elaborate on the incompatible plugins?

[JessicaSachs]

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.

[ghost]

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?

[ghost]

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

[sodatea]

@JessicaSachs If you mean this issue https://github.com/vue-styleguidist/vue-styleguidist/issues/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.

[JessicaSachs]

Nice sleuthing 🕵🏻‍♀️. Yeah, when I was messaging w Bart on Discord in
respect to this issue he said the issue was our sourceType config using
“unambiguous”, but we didn’t document that in the GH issue.

That’s the only issue I can think of off the top of my head. I think it is
likely to change code execution or have downstream affects we’re not
considering.

Solid reasoning on your part. I don’t disagree with any of it, I’m just
paranoid because this isn’t the default for Babel and previously users had
to opt in to do this. I wonder why this wasn’t previously an issue.

On Thu, Oct 31, 2019 at 3:06 AM Haoqun Jiang [e-mail]
wrote:

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

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
https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/babel-preset-app/README.md#usebuiltins
(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.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/vuejs/vue-cli/issues/4773?email_source=notifications&email_token=AAVL4BASUBXPEJ2232MQ6QDQRJ7Y3A5CNFSM4JGYE5TKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWYDYI#issuecomment-548241889,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVL4BCD2CNXKT2DGP7FPVDQRJ7Y3ANCNFSM4JGYE5TA
.

[LinusBorg]

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'
    }
  ]
};

[sodatea]

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