Skip to content

Incorrect transform with async/await #565

Closed

Description

@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.

Activity

  1. developit commented on Feb 16, 2020

    @developit
    Owner

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

  2. Djaler commented on Apr 17, 2020

    @Djaler

    @developit so what about it?

  3. developit commented on Apr 17, 2020

    @developit
    Owner

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

  4. Djaler commented on Apr 17, 2020

    @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
    
  5. Djaler commented on Apr 19, 2020

    @Djaler

    Also, you can just stop using this plugin

  6. developit commented on Apr 23, 2020

    @developit
    Owner

    @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.

  7. Djaler commented on Apr 23, 2020

    @Djaler
  8. changed the title [-]microbundle users should be aware of this issue[/-] [+]Incorrect transform with async/await[/+] on May 6, 2020
  9. PeterBurner commented on Jul 10, 2020

    @PeterBurner
    Contributor

    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 ?

  10. Nick-Lucas commented on Jul 23, 2020

    @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.

  11. developit commented on Dec 18, 2020

    @developit
    Owner

    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.

  12. MartinDawson commented on Oct 28, 2021

    @MartinDawson

    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.

    Just curious but roughly when do you think this will be?

  13. make-github-pseudonymous-again commented on Dec 7, 2021

    @make-github-pseudonymous-again

    Upstream allegedly fixed with rpetrich/babel-plugin-transform-async-to-promises#49 18 days ago.

  14. PeterBurner commented on Jun 1, 2022

    @PeterBurner
    Contributor

    Upstream allegedly fixed with rpetrich/babel-plugin-transform-async-to-promises#49 18 days ago.

    Is there some action required on microbundle side? Eg. updating dependencies.
    Or can this issue be closed?

  15. developit commented on Jun 2, 2022

    @developit
    Owner

    @PeterBurner I believe a new publish of Microbundle would automatically include this as long as we run npm update. Might be better to submit a PR with the part release of this transform bumped though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions