Better polyfill default setting for @vue/babel-preset-app

[LinusBorg]

What problem does this feature solve?

The current implementation of our bable preset sets the useBuiltIns option of the ``babel-preset-envpreset tousage`:

https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/babel-preset-app/index.js#L19

What that means it that only feature that babel comes across during transpilation are actually polyfilled.

The good

This is awesome since it keeps unnecessary polyfills out of our app

the bad

It's bad because any code in node_modules that relies on a poylfill requires the developer to manually inlcude this polyfill in i.e.main.js so it's picked up by babel. This is because we don't run /node_modules contents through babel, so the usage options doesn'T pick up the feature

The alternative

I think the current default is resulting in bad dev UX, because the dev has to know and understand about the way that usage works.

As an alternative, I propose to select entry as the defsault value for useBuiltIns.

The good

Now all features necessary for the targeted browsers will be polyfilled. That ensures that all code from /node_modules relying on a feature that we ourselves don't use will work nonetheless.

The bad

Unnecessary polyfills might be included. To allow the dev to optimize this, we could document how he could switch to usage polyfilling and what the implications are.

What does the proposed API look like?

https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/babel-preset-app/index.js#L19:

-    useBuiltIns = 'usage',
+    useBuiltIns = 'entry',

https://github.com/vuejs/vue-cli/blob/dev/packages/%40vue/cli-service/generator/template/src/main.js

+ import '@babel/polyfill'
import Vue from 'vue'
import App from './App.vue'

[pranavjindal999]

Yes this is a big issue for me.
I use Vuetify and it relies on some new features like Object.values() which I don't use and without including all babel polyfills in main.js, my app breaks in IE.
And including all babel polyfills adds up a weight of around 34 KB gzipped which is costly.

But I also faced an issue where I use Promise.finally in my code but it doesn't get included at all in polyfills, no matter what I do. I had to rely on polyfill service for that, and so I disabled all babel polyfills and just relied on the service.
May be I did something wrong, but didn't change any cli3 configs, it just doesn't work out of the box for Promise.finally

[LinusBorg]

Promise.finally is a stage4 proposal, it's not officially standard yet. and I babel-preset-env only polyfills things that are in the standard right now, as far as I understand it.

you can probably use the include option to force adding such a polyfill.

[pranavjindal999]

I'm not sure but what does following part mean in @vue/babel-preset-app/index.js

Doesn't it mean that it will include all proposals from stage 2 and above?

  // stage 2. This includes some important transforms, e.g. dynamic import
  // and rest object spread.
  presets.push([require('@babel/preset-stage-2'), {
    loose,
    useBuiltIns: useBuiltIns !== false,
    decoratorsLegacy: decoratorsLegacy !== false
  }])

[LinusBorg]

Doesn't it mean that it will include all proposals from stage 2 and above?

It will include all babel-transform plugins for stage two, not polyfills. Those are two different things.

• Babel Tranforms replace new syntax with an equvalent in old syntax.
• Polyfills add features, which can't be replaced with a simple syntax rewrite.

[pranavjindal999]

Thanks man. You comment and you know things !!😄

By the way how do we explicitly add stage x polyfills gracefully with vue-cli 3?

[LinusBorg]

the most easy way would be to import them from core-js which babel-polyfill uses under the hood):

import 'core-js/fn/promise/finally'
// https://github.com/zloirock/core-js/blob/master/fn/promise/finally.js

[yyx990803]

With useBuiltIns: 'entry' and the default browsers target it bloats the hello world app by about 24kb gzipped (vendor chunk size: 21.86kb vs 45.49.kb), which is a lot, especially when a large chunk of them may end up not used at all. I'm not sure if this is something we should use as the default.

Speaking of dependencies, isn't it a convention for any library to clearly state its browser compatibility requirements?

• If a dependency ships code that is ES5, then it doesn't quite make sense for it to use any ES6-only built-ins (except for Promises).

• If a dependency ships ES6 code, then we should explicitly transpile it (with the new transpileDependencies option) which will trigger polyfill detection on it with useBultIns: 'usage'.

I think it's quite rare for a dependency to (1) ship ES5 code that doesn't need transpilation and (2) at the same time requires some ES6 only polyfill to work (again, excluding Promise).

So I think the saner default would be:

1. include a number of commonly needed polyfills by default (Promise, Object.assign). This should cover most use cases (e.g. Vuex). In addition these should only be included if they are actually needed for the project's browserslist targets.

2. For dependencies that does not work in the target environment, the user should explicitly include it in transpileDependencies, which would handle both syntax and polyfills.

3. In the rare case where a dependency ships ES5 code but requires ES6 polyfills, the user need to explicitly include the polyfills.