You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a tracking issue for the Reduce install footprint πΎ project. The purpose of this issue is to keep tracking of the overall status of the project and tasks, and plan everything around it.
See also #29072 which is a spike we'll be doing as part of this project to investigate how to move Storybook towards publishing ESM-only packages.
π’ Want to help?
Make sure you read this issue thoroughly to understand what we want to achieve and how. Do not ask to be assigned to certain tasks, just do them. We won't "reserve" anything to potential contributors, that system rarely work. Help out with what you want, and report findings in this issue, eg. if you've identified potential optimisations in a package. If you open pull requests with your work make sure to reference this issue and tag @JReinhold.
β οΈ Problem
One of the biggest complaints about Storybook is that it's a big and heavy dependency to add to your project. There are muliple ways to interpret the frustration, but one of the most impactful improvements we can make is to reduce the install size of the core Storybook experience.
Throughout the current Storybook 8 releases we've already managed to cut the size significantly, eg. via #27039 and #28519. But there is plenty more work to be done - especially outside the core package - that will enable us to shrink Storybook even further.
π Goals
The high-level goals of this project is to:
Reduce the install size of "the core Storybook experience". That is, the packages that are included in a normal init process, such as storybook, the builders (Vite/Webpack), the renderers (React, Svelte, etc.) and the default addons.
... this includes reducing the dependency graph of mentioned packages, to speedup installation.
Set long-term baselines and goals that will keep us in check, ensuring we don't regress the install-size later.
Build and set up tooling to support these goals. We'll try to find ways that make it easier to maintain lean packages and reduce their footprint. This includes easy-to-access bundle and package analysis tools and reporters.
Identify changes that require a major version bump. This project will conclude before the next major version of Storybook, so we can't make those changes now, but we can prepare them so they are ready when we're closer to the next major release.
This means we are not focusing on performance improvements nor reducing the size of a built Storybook. We still love those improvements, but they are not the major focus here.
π Resources
e18e.dev - provides great guides on how to cleanup, speedup and levelup (?π ) packages.
Storybook is a complex mesh of over 30 packages, therefore analysing "Storybook's" install size will be tackled from two angles:
E2E tests aka sandboxes: Storybook sandboxes represent real-world, minimal projects with Storybook installed. Storybook support countless project configurations, eg. A NextJS project, or a Vite-based Vue project. By initialising Storybook a top these minimal projects, we get a sense of what impact Storybook has on the overall node_modules size and the amount of dependencies added to the project. The upside of this perspective is that it directly focuses on the experience our users get. The downside of this approach - as with most E2E tests - is that it can be "flaky" because a lot of outside factors can impact the project's install size and dependency count. It's also a coarse metric, detecting significant size increases in sandboxes doesn't really help us identify where the increase is coming from. This brings us to...
Unit tests aka packages: Each individual Storybook package will have its own metric on install size and dependency graph. Measuring and detecting size increases at the package-level makes it a lot easier to pinpoint the cause of it. But laser-focusing on packages in isolations can lead to work that makes little difference to the end-user, because they don't use the Storybook packages in isolation. Eg. removing a big dependency from @storybook/react-vite doesn't help if that dependency is still installed by @storybook/core.
Therefore we must keep both metrics in mind, to ensure we improve the experience for the end-user while still getting actionable results on the lower level.
We'll use a breadth-first approach when doing the optimisations across the packages. At the start of the project all, the integration packages have a single task (which also applies to the core): Identify potential optimisations. We'll do that first across all the packages on a high-level, to identify common patterns and find big wins first. This ensures that we don't laser focus on eg. removing 15 KB from @storybook/react when we could instead have removed 12 MB from @storybook/vue3-vite.
With that said, there are already known big wins in the core packages that might get a higher priority than looking into some of the integration packages.
There are many approaches and tools to optimising package's size and dependencies and it's not a one-size-fits-all. https://e18e.dev/guide/cleanup.html is a good primer on how to approach it. At a high-level we'll:
Use https://pkg-size.dev to identify and monitor the size of the packages and their dependencies
Use ESBuild's metafiles that are produced when building all the packages, to identify and monitor the packages' internal structure and bundled dependencies.
This section includes all the actual package optimisations that we want to make. The list is highly dynamic and should change a lot during the project.
The content you are editing has changed. Please copy your edits and refresh the page.
Ideally we'd want to set up some tooling that allows to easily inspect package and dependency sizes, to make it easier to optimise these areas. It's still TBD what shape or form these could take.
The content you are editing has changed. Please copy your edits and refresh the page.
Based on the baseline calculations, I think it's fair to skip the following packages along with @storybook/addon-essentials for now, because they are "tiny" compared to the rest of the packages here:
π§βπ€βπ§ Who: @JReinhold and @ndelangen
This is a tracking issue for the Reduce install footprint πΎ project. The purpose of this issue is to keep tracking of the overall status of the project and tasks, and plan everything around it.
See also #29072 which is a spike we'll be doing as part of this project to investigate how to move Storybook towards publishing ESM-only packages.
π’ Want to help?
Make sure you read this issue thoroughly to understand what we want to achieve and how.
Do not ask to be assigned to certain tasks, just do them. We won't "reserve" anything to potential contributors, that system rarely work. Help out with what you want, and report findings in this issue, eg. if you've identified potential optimisations in a package. If you open pull requests with your work make sure to reference this issue and tag @JReinhold.
One of the biggest complaints about Storybook is that it's a big and heavy dependency to add to your project. There are muliple ways to interpret the frustration, but one of the most impactful improvements we can make is to reduce the install size of the core Storybook experience.
Throughout the current Storybook 8 releases we've already managed to cut the size significantly, eg. via #27039 and #28519. But there is plenty more work to be done - especially outside the core package - that will enable us to shrink Storybook even further.
π Goals
The high-level goals of this project is to:
init
process, such asstorybook
, the builders (Vite/Webpack), the renderers (React, Svelte, etc.) and the default addons.This means we are not focusing on performance improvements nor reducing the size of a built Storybook. We still love those improvements, but they are not the major focus here.
π Resources
π Spreadsheet with package stats
π¬ Methodology
Storybook is a complex mesh of over 30 packages, therefore analysing "Storybook's" install size will be tackled from two angles:
node_modules
size and the amount of dependencies added to the project. The upside of this perspective is that it directly focuses on the experience our users get. The downside of this approach - as with most E2E tests - is that it can be "flaky" because a lot of outside factors can impact the project's install size and dependency count. It's also a coarse metric, detecting significant size increases in sandboxes doesn't really help us identify where the increase is coming from. This brings us to...@storybook/react-vite
doesn't help if that dependency is still installed by@storybook/core
.Therefore we must keep both metrics in mind, to ensure we improve the experience for the end-user while still getting actionable results on the lower level.
We'll use a breadth-first approach when doing the optimisations across the packages. At the start of the project all, the integration packages have a single task (which also applies to the core): Identify potential optimisations. We'll do that first across all the packages on a high-level, to identify common patterns and find big wins first. This ensures that we don't laser focus on eg. removing 15 KB from
@storybook/react
when we could instead have removed 12 MB from@storybook/vue3-vite
.With that said, there are already known big wins in the core packages that might get a higher priority than looking into some of the integration packages.
There are many approaches and tools to optimising package's size and dependencies and it's not a one-size-fits-all. https://e18e.dev/guide/cleanup.html is a good primer on how to approach it. At a high-level we'll:
We can take
@storybook/core
as an example:esbuild
tojiti
for preset handlingΒ #29082express
topolka
Β #29083@storybook/core
(not currently public) shows that Prettier makes up a big part of the bundled output. Can we replace it, or remove it? See Minimize the bundling ofprettier
in@storybook/core
Β #29084π© Milestones
π Baselines and Bechmarks
See spreadsheet detailing all the packages.
Tasks
π§ Optimisations
This section includes all the actual package optimisations that we want to make. The list is highly dynamic and should change a lot during the project.
Existing work that needs triage
lodash
withes-toolkit
#28981lodash/merge
&lodash/mergeWith
with an alternative #28663π¦ Core Packages
Package replacements
esbuild
tojiti
for preset handling #29082express
topolka
#29083chalk
topicocolors
#28262qs
topicoquery
#28315recast
#29143handlebars
to simple string concats #29167empathic
#29103fs-extra
tonode:fs
#29104fs-extra
with the native APIs #29126react-popper-tooltip
with@radix/react-tooltip
or Floating UI #29161Architectural changes
prettier
in@storybook/core
#29084react
,react-dom
in the manager #29166𧩠Integration Packages
Builders
@storybook/builder-vite
@storybook/builder-webpack5
Renderers
@storybook/react
@storybook/vue3
@storybook/web-components
Frameworks
@storybook/react-vite
@storybook/react-webpack5
@storybook/nextjs
@storybook/experimental-nextjs-vite
@storybook/angular
@storybook/vue3-vite
@storybook/vue3-webpack5
@storybook/sveltekit
@storybook/svelte-vite
@storybook/web-components-vite
@storybook/web-components-webpack5
Addons
@storybook/addon-docs
@storybook/blocks
@storybook/addon-interactions
@storybook/addon-actions
@storybook/test
@storybook/addon-controls
@storybook/addon-measure
@storybook/addon-outline
@storybook/addon-backgrounds
@storybook/addon-toolbars
@storybook/addon-viewport
@storybook/addon-onboarding
π οΈ Supporting Tooling
Ideally we'd want to set up some tooling that allows to easily inspect package and dependency sizes, to make it easier to optimise these areas. It's still TBD what shape or form these could take.
π Essential tooling
β¨ Nice-to-have tooling
knip
to identify unused files/exports #29106Related: evanw/esbuild#3909
π€· Misc
π Wrap up
π₯ Breaking optimisations
@storybook/icons
in@storybook/core
#29159react-syntax-highlighter
withshiki
#29160π Nice-to-haves
@storybook/addon-links
from the default addons that are part ofinit
#29073The text was updated successfully, but these errors were encountered: