Storybook: Distribute esm without es5 and polyfills

[LarsDenBakker]

Is your feature request related to a problem? Please describe.
All the storybook packages are compiled to commonjs, es5 and include polyfills. This contributes to quite a growth in codesize, and removes (some of) the ability to do efficient tree shaking.

When using the default storybook setup, this doesn't create many problems. The tree shaking of es modules could help serve less code, but webpack handles commonjs and you always serve es5 for all browsers. This change does enable serving non-es5 for modern browsers, since it's only needed for IE11 at this point.

When using storybook in different context, like the standalone or in our case we are prebundling it, the increase in codesize is unfortunate. We check the browser's user agent, and only do code compilation if necessary for that specific browser. Not having to ship compiled classes, async functions, for of loops, object spread etc. is quite a lot less code We also have a different way of loading polyfills, so we end up with duplicates for a lot of polyfills.

Describe the solution you'd like
Next to the existing build, ship a build of es modules without polyfills and compiled only to remove types, jsx and non-standard syntax. This is mostly a few tweaks to the babel config.

Are you able to assist bring the feature to reality?
yes

[shilman]

@LarsDenBakker what will the build output look like?

[LarsDenBakker]

@shilman there would be the commonjs output there is now, and a esm output side by side.

there are different ways to go about the folder structure, for example redux has a dist and a es folder: https://www.runpkg.com/[email protected]/es/redux.js

Vue ships an es module variant in the dist folder directly: https://www.runpkg.com/[email protected]/dist/vue.esm.browser.js

Angular has a lot of different ouputs in separate folders: https://www.runpkg.com/?@angular/core@8.2.14/esm2015/core.js

[shilman]

@LarsDenBakker that sounds reasonable to me! But I'm also pretty ignorant about this stuff. @Hypnosphi @ndelangen @tmeasday any thoughts?

[tmeasday]

Seems like something a lot of packages (although typically they are runtime dependencies). I guess given we are expanding in that direction we'll need to start doing it too 🤷‍♂ I also am pretty clueless about all the technical details.

[ndelangen]

I'd love to use pika/pack for compiling all storybook packages.

Pika has this figured out how to ship packages with multiple output types.

I've experimented with removing polyfills & core-js, but it's a lot of trial and error.
I haven't even attempted to compile packages with pika pack yet. https://github.com/storybookjs/storybook/pull/9231

I know @ghengeveld has some experience with pika and I talked to the author (@FredKSchott) a while ago, but the process of adopting it feels monumental at the moment.

[LarsDenBakker]

@ndelangen Pika is pretty interesting, but I agree it's quite a big change to do.

My proposal can be achieved quite simply with a few additions to the babel config, I will come up with a concrete proposal then we can continue the discussion from there.

[ndelangen]

@LarsDenBakker that'd be super interesting to see what you could do to help us in this direction.

I'm meeting with the author of Pika next monday btw. Any custom work and config we do to make this happen would be around for a while, the babel config is already quite complex as it is, and already not quite the way it should be IMHO.

[LarsDenBakker]

Still interested in this one :)

[hipstersmoothie]

This issue is a blocker for trying to enable tree-shaking for any of the code used by storybook. (https://github.com/storybookjs/storybook/issues/9282)

[shilman]

We're going to do a bunch of perf work as part of 6.1. @LarsDenBakker @hipstersmoothie @ndelangen if somebody wants to give this a try, I think we're finally in a good position to consume/ship that.

[hipstersmoothie]

I've already started 🥳

[shilman]

You're awesome @hipstersmoothie 💯

[FredKSchott]

👀 👀 👀 exciting! If you're shipping ESM, it would be worth experimenting with Snowpack as a potential ESM-optimized dev server and production build tool. From our site:

Snowpack is an unbundled front-end development environment that leverages JavaScript's native module system (ESM) to start up & rebuild changes in 50 milliseconds or less. When it's time to deploy, Snowpack works with your favorite tools (including bundlers) to create a fast, production-ready build.

[shilman]

@FredKSchott it's actually one of the most upvoted open issues in the storybook repo: https://github.com/storybookjs/storybook/issues/10987. We're focusing on performance in 6.x, so that's fair game!

[FredKSchott]

My heart breaks for those users reporting 10-15 min webpack builds 😭

That's great to hear, just let me know how I can be helpful/useful!

[LarsDenBakker]

FYI we've been using https://github.com/open-wc/storybook-prebuilt for quite some time now in https://github.com/open-wc/open-wc/tree/master/packages/demoing-storybook. It builds storybook to an es module using rollup, and it's been working very well for us.

The big downside is having to keep it up manually (we didn't update to v6 yet, for instance), so having this in storybook itself would be great :)

I said in this thread I would come up with a concrete proposal, but in v5 there were some hurdles with the config and some dependencies. I didn't look into v6 yet, perhaps it will be easier to do now!