[epic] storybook

[43081j]

storybook's dependency tree depends on the flavour of entrypoint you use.

so for this example, let's use the web-components package: https://npmgraph.js.org/?q=@storybook/web-components-vite

there's quite a lot of deep subtrees we can probably trim out here.

good subtrees to remove are:

• assert (graph)
• qs (graph)
• read-pkg-up (graph)

assert

Depended on by:

• @storybook/docs-tools
  • tracked in #29
• @storybook/csf-tools -> recast
  • tracked by benjamn/recast#1387
  • tracked by storybookjs/storybook#26286

qs

Depended on by:

• express - not sure how likely PRs are to express
• body-parser (express) - again not sure how likely PR acceptance is
• @storybook/core-common - may already be gone in 8.x!
• @storybook/channels - used here
  • tracked by storybookjs/storybook#26285
• @storybook/router - used here

In most cases, we can likely either:

• Use URLSearchParams
• Use fast-querystring (if we need nesting, arrays, etc)

read-pkg-up

This has some use but the dependency tree is bloated for what it is, and there are more performant solutions.

If possible, we should use read-package-json-fast from npm themselves.

We could use fd-package-json: https://github.com/es-tooling/fd-package-json

[43081j]

we can now replace read-pkg-up with fd-package-json: https://github.com/es-tooling/fd-package-json

[benmccann]

express - not sure how likely PRs are to express

express itself is rather bulky and could be swapped out. I just did that in the Svelte repo, which luckily only took me a few lines there: https://github.com/sveltejs/svelte/pull/12155

[43081j]

you're right. i forgot to update this issue too!

i started the work in storybookjs/storybook#27045

although polka is tempting too. though i may do that in a later PR since it'll be an easier move than this one