Snowpack

[phaistonian]

Snowpack makes development both fun and instant.

It'd be great If, somehow, it'd work with Storybook - by optionally replacing webpack.

A quick look at the Snowpack docs indicates that it's rather doable.

[o-alexandrov]

it makes sense to keep this open as the opportunity to get rid of bundling from the process, resulting in extremely quick iterations, would be awesome to be built into storybook

[desireco]

I am willing to poke around if someone who is knowledgable wants to pair. It would be huge if we could figure out how to make this work. I have sizable storybook instance.

[techieshark]

@desireco I'm curious - how long does storybook take to start up on your (sizeable) storybook instance? Mine is not large but is taking over two minutes which is why I'd love to see snowpack used.

[desireco]

@techieshark 10-15 mins.

[shilman]

that's nuts guys. can you share more about your respective projects? chromatic's storybook has 1500 stories including entire pages and takes 40 seconds to build.

FYI, even this is waaay too long and we'll be devoting a bunch of time to perf in 6.1, including possibly this issue if anybody can share a POC.

[phaistonian]

@desireco it all comes down to the webpack config you use.

If you invest time to tweak it, you can get quite decent build times.

[fcamblor]

Hi there !

FYI I achieved to integrate storybook in a snowpack-based project using a "statically generated" storybook 5.3 based on openwc's prebuilt-storybook.

Fork of this prebuilt-storybook is here : https://github.com/fcamblor/fcr-storybook-prebuilt-wrapper (I had to tweak some stuff here and there (most important one being the possibility to avoid absolute imports in the wrapper, backed by this PR https://github.com/open-wc/open-wc/pull/1694 which didn't get enough traction)

Snowpack + storybook demo available in this starter : https://github.com/fcamblor/lit-element-typescript-sass-constructible-stylesheet-storybook-starter (I decided to keep my project and storybook completely separated, storybook being into a dedicated folder so that its dependencies don't transpire into the main project)

Downsides of this are :

• this works only with a specific version of storybook (in my case, 5.3) and if we want to follow new versions of storybook, you have to adapt prebuilt storybook to fit changes occured on the new versions (didn't tried to adapt against storybook 6 yet)
• addons are kind of "hardcoded" in the prebuilt version.. it is not complicated to add some, but here again you have to update prebuilt version of storybook to take it into consideration

Hope this can help and I would obviously be interested into completely replacing webpack with snowpack ... this would remove the prebuilt-storybook dependency and would make things definitely more maintainable on the long term :-)

[shilman]

@fcamblor this is awesome, thanks so much for sharing! 💯

we're fans of prebuilt-storybook and will be looking at ways of incorporating some of those improvements into storybook 6.x to make this all integrate better and not be tied to a specific storybook version.

[techieshark]

@shilman my repo isn't open but if it helps I can add you as a contributor so you could test it. It may just be my computer - on a good day it's 33-45 seconds.

[FredKSchott]

Hey everyone, maintainer of Snowpack here! 👋

@ndelangen and I chatted about this a while ago, so I know he's excited about the ESM story for Storybook as well. I'd love to help out however I can on a Snowpack + Storybook integration. Feel free to reach out with any questions or thoughts.

[ndelangen]

@fcamblor @desireco

I'd love to talk to you about a path going forwards having snowpack as an options in storybook.

schedule a meeting with me? https://calendly.com/ndelangen/storybook

[desireco]

@ndelangen I really appreciate the offer. I am currently swamped with work, but I will see to find time for this.

[paralin]

I'm interested in a Snowpack plugin which brings in Storybook to a project.

[zachintosh]

Yesssssss.

[ndelangen]

Offer is open to anyone interested in working on this!

[MIreland]

@ndelangen - Could you give a brief overview of the scope of work involved?

[ndelangen]

@MIreland I've never used snowpack before, but we're very interested in the option of switching from webpack to snowpack, to ship modern ESM to the browsers that support it.

[o-alexandrov]

I have tried adding snowpack only for development bundling, while keeping webpack. And started to have seen issues, fixed some, but then I realized:

• I am introducing a second bundler, when:
  • initial bundling with webpack 4 at that time was about 20 seconds on my laptop
  • HMR took from 0.5s to 1s

When talking about bundling, it's not only JavaScript, but also: HTML, Favicons, PWA-specific scripts, sometimes bundled JS app is a hybrid app (adding more complexity to the bundling), sometimes CSS & pre-processors, etc., so for me it's obvious now:

• we cannot rely on Snowpack (being a relatively new solution) to handle all such cases in production reliably at this time
  • even if we can, adding webpack on top of snowpack, it adds complexity and potential unpredictability with upgrades
  • there could be bundler-specific issues
  • if you are still not convinced about reliability, look at the changelog of webpack and realize, for example: how many different module concatenation scenarios there are for different types of output
• webpack's HMR is not drastically different from snowpack, so it's not really noticeable
• more maintenance time expense: additional deps to familiarize with and support integration of

With introduction of webpack 5, our initial bundling dropped from 20s to 13s, and HMR takes up to 0.5s now.

• then, there is built-in now hard disk caching which makes initial bundling to happen in up to a couple of seconds

And finally:

• the author of webpack mentioned ESM is their current priority; most probably not right when the feature is available, but a bit later we would probably see a switch for "no bundling for JavaScript" in development.
  • or probably configuring the output target for development process is the only thing that we would need to do in webpack v5 to match the performance of Snowpack

So let me please withdraw my interest from the first comment on this topic above. I believe sticking to a single bundling process is the way to go. On a side note, also removing rollup when creating libraries once webpack supports ESM output to decrease maintenance complexity.

[chrislambe]

@o-alexandrov to clarify something you mentioned: Snowpack is a developer build tool, not a bundler. Snowpack does not produce production builds/bundles. It does have a plugin architecture for integrating bundlers like Webpack: https://www.snowpack.dev/#bundle-for-production

Your point about about Webpack pushing for ESM builds is interesting, though. I'm curious if it will result in similarly low (re)build times.

Edit As it relates to my specific use case (isolated development of application components as opposed to building a component library package), this is particularly relevant:

Snowpack treats bundling as an optional production optimization, which means you’re free to skip over the extra complexity of bundling until you need it.

I don't produce/ship a production build of my stories, and thus have no need for a bundler.

[MIreland]

My understanding is that Snowpack uses esbuild under the hood, which is likely to have substantial performance improvements even for unbundled states (I would think?):

[shilman]

Related: We released https://github.com/storybookjs/storybook/pull/12707 yesterday which means that the "manager" UI only builds when it changes. This comes with a better UI and also frees up CPU for building the user's "preview" bundle. Should help with webpack, snowpack, or whatever we end up with on the user's side.

Try it out today in 6.1-alpha:

npx sb@next upgrade --prerelease

[schickling]

Now that 6.1 has been out for a while, is there any progress update on this for the upcoming 6.2?

[shilman]

@schickling we have a rough design for supporting both webpack4 and webpack5 side by side, feedback welcome. this may go out in 6.2 but still unsure. once we get this going, adding another package for snowpack should also be possible.

[ovidiuch]

If anyone's curious, this is how React Cosmos integrates with Snowpack. Not trying to promote Cosmos on a Storybook thread, just wanted to share how we do it. Storybook and Cosmos are similar in many respects so you might be able to get some inspiration.

The Cosmos integration is pretty verbose and requires some manual wiring, compared to using webpack. Essentially, you have to manually add a Snowpack route for the preview iframe (we call it the renderer), which loads an auto-generated map of all the user's fixtures (you call them stories), and point the main UI to load the new Snowpack route as the iframe URL. Not ideal, but I think it's a good starting point for people who are eager to use Snowpack, like myself.

Happy to share more from my (limited) Snowpack experience to anyone who is looking to replicate something similar on the Storybook side. I'm also curious to hear ideas for simplifying this integration by making use of Snowpack's JS API, so I'll be following this thread to see what solution you come up with.

[ndelangen]

@skidding I'd love to learn more, would you have the time to do a knowledge sharing zoom meeting some day? https://calendly.com/ndelangen/storybook

or reach out to me on our discord: https://discord.gg/js3AjMg6dW

[ovidiuch]

@skidding I'd love to learn more, would you have the time to do a knowledge sharing zoom meeting some day? https://calendly.com/ndelangen/storybook

or reach out to me on our discord: https://discord.gg/js3AjMg6dW

Happy to help. Just sent you a DM.

[bard]

I have a create-react-app project where I use Snowpack in dev and WebPack 4 for the prod build.

Storybook was taking 6+ seconds to refresh simple components; I brought it down to around 3s by disabling DocgenPlugin, ESLintWebpackPlugin, and ForkTsCheckerWebpackPlugin, and further to around 2s by enabling the turbo build plugin with optimizationLevel: 3 . At some point I tried the Webpack 5 builder, but it made no significant difference and I didn't record the time.

Unfortunately, at 2s per refresh I still find it unusable for interactive development. Maybe I've been spoiled by Snowpack, but anything >1s quickly drives me up a wall.

In the end, I added a new /canvas route to the application, only available in development, where I develop stories interactively with the benefit of Snowpack's fast feedback. Stories are then fully reusable in Storybook. The idea is simple:

import * as Button from './Button.stories'

export const Canvas: React.FC = () => {
  const Story = Button.Basic
  return (
    <div>
      <Story {...Story.args} />
    </div>
  )
}

// ...
  <Router>
    <Switch>
      <Route ... />
      <Route ... />
      {process.env.NODE_ENV === 'development' && (
        <Route path="/canvas" component={Canvas} exact={true} />
      )}
    </Switch>
  </Router>
// ...

(In reality, I'm importing several *.stories.tsx files, and building a two-level menu to switch stories like the one in Storybook, but the above is the essence of it.)

Kudos to the forward-thinking people who came up with CSF, this is only possible because of that.

The downsides of this strategy are 1) when you change component args in story files, the changes aren't picked up and you need a full page reload (perhaps related to https://github.com/snowpackjs/snowpack/discussions/2010); and 2) if you use decorators, you need to write some more support code.

---

My .storybook/main.js:

const { inspect } = require('util')

module.exports = {
  stories: [
    '../src/**/*.stories.@(js|jsx|ts|tsx)',
  ],
  addons: [
    '@storybook/addon-links',
    '@storybook/addon-essentials',
    '@storybook/preset-create-react-app',
    ['storybook-addon-turbo-build', { optimizationLevel: 3 }],
  ],

  webpackFinal: async (config, { configType }) => {
    config.plugins = config.plugins.filter(
      (p) =>
        !inspect(p).match(
          /^(DocgenPlugin|ESLintWebpackPlugin|ForkTsCheckerWebpackPlugin)/,
        ),
    )

    return config
  },
}

[sebastienbarre]

@bard I think I could deal with 2 seconds. Could you give us more details about "disabling DocgenPlugin, ESLintWebpackPlugin, and ForkTsCheckerWebpackPlugin, and further to around 2s by enabling the turbo build plugin with optimizationLevel: 3" ? Thanks

[bard]

@sebastienbarre the .storybook/main.js above, plus npm i storybook-addon-turbo-build, should be enough. Lower the optimization level if things break.

[justgook]

Doesn't this #14545 (didn't check yet) opens ability to use storybook with snowpack?

[shilman]

14545 means that if somebody wrote an experimental snowpack builder, users would be able to try it out without having to fork storybook. AFAIK nobody's written that builder yet. (but if anybody's interested, I'd be happy to guide!)

[justgook]

I'm kind of have idea for that, tryout, check what it spits out, and see what it needs.. and if at all it is possible to build snowpack into storybook or storybook into snowpack.

[justgook]

Main point of snowpack - that it acts just as middleware for each file - so it results just 1:1 if imports.. only way that I can imagine how it can work with storybook and custom bundler - is just provide full files that is required, and give snowpack ability to build/serve it.. but for that storybook should become something like Storybook prebuilt - that acts just like bare framework that can be included as part of application, or just proxy all file requests to different HTTP server.. (just personal opinion, still would like investigate that question, and maybe get some help / feedback)

[shilman]

@justgook vite is also doing browser-native ESM for the dev server and there is a WIP vite builder here: https://github.com/eirslett/storybook-builder-vite

if you jump onto the storybook discord, the authors are available for discussion in the #vite channel and are also interested in snowpack: https://discord.gg/storybook

[ndelangen]

@justgook I'd love to pair on this together with you.

If you have the time and interest of course! I know the ins and outs of storybook, the webpack builder.

If you'd like to schedule a meeting to talk about this: https://calendly.com/ndelangen/storybook

[Manubi]

Any news on this one? 😄

[aryaniyaps]

small bump on this. I would really like to see smaller wait times! 😄

[siva-sundar]

Curious to know if there are any updates 😀

[fabb]

Ladle looks interesting, a drop-in replacement for Storybook built with Vite instead of webpack and therefore a lot faster: https://www.ladle.dev/blog/introducing-ladle/

[shilman]

@fabb check out storybook's vite builder, which is also much faster https://storybook.js.org/blog/storybook-for-vite/

[siva-sundar]

@shilman Vite builder for storybook works but it has some issues like frequent pre-bundling dependencies. https://github.com/eirslett/storybook-builder-vite/issues/75

[IanVS]

Snowpack is no longer maintained, so I don't think Storybook will create a builder for it. If you're tied to Snowpack and want to create your own Storybook builder, hit me up and I can walk you through how the vite builder works as a bit of an example.