async/await support

[alexdilley]

@chrisvfritz to support ES2017 async/await, this appears to be the required config – the polyfill.io service does not provide this feature; or: vue-cli generated apps get this via @vue/babel-preset-app but it's hence removed by passing the useBuiltIns: false option.

Is this something you're okay with being added to the project?

[chrisvfritz]

This is definitely welcome! 🙂 I think the correct way to handle it with babel-preset-env (which is used by @vue/babel-preset-app) might be the include option. Or, it might actually be safer to explicitly exclude everything that Polyfill.io covers.

[alexdilley]

The include option sounds like a more seamless solution, but I couldn't get that to work. I assume it required something like the following change?:

--- a/.babelrc.js
+++ b/.babelrc.js
@@ -6,6 +6,7 @@ module.exports = {
         // Disable Babel's polyfills, replaced by the
         // polyfill.io service in index.html
         useBuiltIns: false,
+        include: ['transform-runtime'],
       },
     ],
   ],

Or, it might actually be safer to explicitly exclude everything that Polyfill.io covers.

That'd be a big list though, right? And starts the defeat the purpose of using the polyfill service to avoid the yak-shaving involved when wanting to utilise [other] unsupported ES features?

[chrisvfritz]

Hm, upon further digging, it looks like the include option always includes the specified polyfills, so it's not what we'd want anyway. The final result I'm going for is that async/await will be available for use, but the regenerator runtime will only be included if it's actually used in the code (and needed by the targeted browsers). That way, we won't be adding an extra 2.3KB gzipped to build for the many people/teams that will never use async/await.

I worry that useBuiltins set to usage with a long excludes list might currently be the only way to achieve this ideal scenario. If that's the case, I wonder if it'd be best to just have users include it themselves if they want it - though we could make that easier with comments in .babelrc.js. What are your thoughts?

[alexdilley]

I liked this project's approach of using the polyfill.io service because of the download overhead it circumvents for the majority of end-users using modern browsers. But I often wonder whether avoiding including the core-js libs in the vendor bundle becomes more of a pain point than it's worth. I'm personally still in two minds about this.

(I don't know if the JS community in general over-nitpicks KB count – I myself can vouch that it's certainly possible to become obsessive...damn you, webpack-bundle-analyzer! Anyway, that's an aside!)

I think the long excludes list option will be error-prone and may serve to confuse (although may consequently provide a source of documentation!). It's a list that'd need to be individually maintained per-app as different features are utilised too? Unless I'm misunderstanding, I'd avoid this option.

Not using async/await in an "enterprise" app – is that less common given its fairly wide adoption of making async code appear more, well...synchronous? I got a sense that vue-cli is leaning in this direction anyway/too. But perhaps the right compromise is to have it as commented code only so users can choose to opt-in. I guess it's a question of how "very" your "very opinionated architecture" project tagline equates ;)

[chrisvfritz]

Nevermind, this is fine. 😄 I had a brain lapse, forgetting that the transform runtime will only polyfill features that are actually used, so people who want to use async/await can and those who don't won't be affected.

That said, I also underestimated the size hit for using async/await the first time - nearly 10KB gzipped. 😬 I just updated the comment with a note about that.

[alexdilley]

👍 Thanks.

Many might find that in reality the increase in (gzipped) bundle size could be as low as 2.37KB (the cost of regenerator-runtime alone) because they may have pulled some or all of the 8.63KB core-js overhead via other ES6+ conveniences (e.g. certain utilisations of the spread operator – [...arrayVar, 'baz'] – will pull in the majority of it)...unless you just support Chrome or something 🙄. I find trying to avoid core-js fragments getting into a build is nigh-on impossible, even when pairing with the polyfill.io service.

Related, I opened vuejs/vue-cli#992 earlier – I notice big savings in build size by reversing the dll mode option you've set (currently having the effect of the opposite of what you'd expect because there's perhaps a bug).

[chrisvfritz]

Good point about the size variation. I updated updated the comment, but then eventually just decided to remove it altogether. 🙂

Also good find on the dll mode option. I'll try to investigate soon unless someone else beats me to it.