Incorrect transform with async/await

[CyriacBr]

microbundle uses the babel plugin babel-plugin-transform-async-to-promises which has this serious bug as it changes the behavior of your code once transpilled.
Sharing that here as this could save a few hours of headache and insanity to someone. I wasn't that lucky.

[developit]

For sure. I think short term we can detect switch cases within async functions and throw an error.

[Djaler]

@developit so what about it?

[developit]

@Djaler this is an upstream issue that needs to be fixed in the Babel plugin.

[Djaler]

@Djaler this is an upstream issue that needs to be fixed in the Babel plugin.

I mean this :

we can detect switch cases within async functions and throw an error

[Djaler]

Also, you can just stop using this plugin

[developit]

@Djaler the value proposition of microbundle is that output is unabashedly minimal. Switching to regenerator output would be a very large step in the wrong direction. That being said, depending on how modern output moves forward, it might be possible to sacrifice some of the output quality in legacy builds as long as most package consumers end up with the modern version. Currently that's not the case, but it may be soon.

[Djaler]

By sacrifice quality you mean wrong, not working code?

[PeterBurner]

is there a workaround for now?
will things break if we pin babel-plugin-transform-async-to-promises to v0.8.14?
or do we have to downgrade to microbundle v0.11.0 ?

[Nick-Lucas]

the value proposition of microbundle is that output is unabashedly minimal. Switching to regenerator output would be a very large step in the wrong direction

Given that the upstream package hasn't had a commit since October 2019, and this critical bug was reported way back then, wouldn't it be a good idea to look at alternatives from shipping a broken dependency? If there's a working version that could be pinned like @PeterBurner suggests, then that's great, but regenerator is very common in the wild, so it doesn't really seem like a bad choice if it's actually stable.

[developit]

The workaround is to avoid direct combined usage of async/await and switch. We can't produce acceptable output for it with or without regenerator, so consider it unsupported by Microbundle.

The fact that regenerator is common does not make it the right solution. Regenerator is routinely duplicated tens or hundreds of times in bundles because a large percentage of npm modules bundle it for the sake of correctness. Unfortunately, no tools exist that can fix that situation, which leaves us with two bad options: ship regenerator and bloat 16,000 npm modules, or ship async-to-promises and advise Microbundle users to avoid the problem syntax. We only transpile first-party code, so this only applies to code written by the person configuring the bundler - the code that is easiest and most valuable to change.

Ultimately, Microbundle isn't webpack or Rollup - it's not a general-purpose tool and it doesn't cater to the same breadth of use-cases. It exists purely to provide the smallest output for the subset of modern input that we be compiled with minimal overhead. This particular async/await issue is gnarly, sure, but keep in mind Microbundle and indeed most meta-bundlers run Babel in loose mode anyway, which has far more edge cases in order to produce output of an acceptable size.

I have yet to find any reasonable solution to this aside from advocating for modern JS output that is (thankfully) immune to the problem, which is exactly what we are doing. Once enough bundlers (or really bundler configs) support modern npm modules, this problem goes away entirely. At that time, we can happily switch to generating larger more accurate ES5 bundles for the rare cases in which someone would end up using them.