Top-level `await` in stories break them. Storybook 6.3, Webpack 5

Describe the bug If a top-level await is used inside a .stories.tsx, the stories break - they are not being displayed in storybook anymore.

To Reproduce Add storybook with webpack5 builder to a React Project, start it:

npx sb@next init --builder webpack5
npm i
npm run storybook

=> The default example components are being displayed, including Button.

Change Button.stories.tsx to contain a top-level await:

import React from 'react';
import { Story, Meta } from '@storybook/react';
import { Button, ButtonProps } from './Button';

await Promise.resolve();

export default {
  title: 'Example/Button',
  component: Button,
  argTypes: {
    backgroundColor: { control: 'color' },
  },
} as Meta;

// [...]

=> The component Button is not being displayed anymore in storybook, direct URL access does not work anymore, too. It is gone.

Why is this important?

Using Webpack 5, we can use module federation to create a federated Storybook; A storybook dynamically referencing components from other projects. This would make integrating components from other microfrontends much easier. The standard way to import these federated components is with a top-level await like this:

const Button = (await import('app2/Button')).Button;

System

╰❯ npx sb@next info                                                                                                                                                                                                              130 ↵

Environment Info:

  System:
    OS: macOS 11.4
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 14.15.1 - ~/.asdf/installs/nodejs/14.15.1/bin/node
    Yarn: 1.22.10 - ~/.asdf/installs/nodejs/14.15.1/bin/yarn
    npm: 6.14.8 - ~/.asdf/installs/nodejs/14.15.1/bin/npm
  Browsers:
    Chrome: 91.0.4472.77
    Firefox: 88.0.1
    Safari: 14.1.1

---

Happy to repro a repo using Webpack module federation if it is more complicated than just the top-level await. Thanks for the help.

[MichaelAllenWarner]

In case anyone’s wondering, I can confirm that top-level await is working now in 6.4.0-beta.1, with the storyStoreV7 feature turned on (using Webpack 5’s experiments.topLevelAwait). Have to include your Storybook flavor as an add-on in main.js. The a11y add-on doesn’t seem to be working yet (for storyStoreV7 I think).

[tmeasday]

@MichaelAllenWarner

For what it’s worth: if there were an option to turn on top-level await in v6 at the cost of breaking storyshots, I would use it.

Sure, in 6.4 we will have a storyStoreV7 feature flag that opts into the new store. We may or may not figure out a way to make Storyshots work with it (ultimately we are transitioning to a new test runner, but probably not in 6.4).

I handle this in Storybook/HTML with a global async loader, where each story-function does nothing but return what the global loader passes it, and where a story’s rendering logic is offloaded to a custom async .render() method

Well the actual renderToDOM function of a framework is allowed to be async, and in fact we have @storybook/server for exactly this kind of use case – you might want to look at this for a more established pattern of what you are doing.

With top-level await, I’d still have to use async loaders for each story, but I’d be able to import a Twig template into a .stories.js file, extract some markup from it at the module-level, and use the markup directly in a story’s args. Much cleaner.

That seems cool, although if you look at @storybook/server you see a different approach to generating things like args from the server.