[RFC] Core package consolidation

[shilman]

Summary

Consolidate all of Storybook's core packages into a single package to reduce install size, dependency conflicts, security warnings, hoisting issues, and unnecessary APIs

Problem Statement

Storybook’s dependency setup is a mess. Our monorepo currently contains ~75 packages, which all depend on one another in a tangled structure. Installing React Storybook into an empty project brings ~120M and 400+ packages with it. This leads to a variety of problems, all of which frustrate users and reflect badly on Storybook:

Problem	Description
Slow install	Storybook has lots of dependencies and those dependencies have dependencies, leading to a long waterfall-style installation pattern that’s slow. Prebundling these dependencies is harder without a single core package.
Large install	Storybook has a lot of dependencies, and as regular dependencies they need to be installed in their entirety. Prebundling allows us to only ship the code for the pieces of the packages that we actually use.
Dependency conflicts	We get many bug reports where multiple versions of Storybook packages are installed and those packages are not compatible with one another. This is such a problem that we’ve developed a custom tool sb doctor to check for it.
Security warnings	We get many bug reports with security warnings about packages that Storybook brings into their projects. We know of at least one project (sentry) that dropped Storybook because of this issue. We can overcome this by prebundling packages into ours, prebundling is harder without a single core package.
Hoisting issues	We get bug reports with security warnings about Storybook’s dependencies conflicting with the user’s dependencies and causing bugs. We know of at least one project (sentry) that dropped Storybook because of this issue. We can overcome this by prebundling packages into ours, prebundling is harder without a single core package.
Unnecessary APIs	We have public APIs that grow our surface area but only exist to expose functionality from one Storybook package to another. These APIs could be made internal if we consolidate our core packages into one.
Confusing dependency requirements	Sometimes users need to use API’s from a low-level package like @storybook/manager-api , but depending on their project tools they need to also add this package as an explicit dependency. ESLint might or might not require it and the package managers behave differently, resulting in confusing errors for the users.

Non-goals

• CLI optimization. Package consolidation might help reduce the size and install time of the CLI, but that is not an explicit goal of this project. For more information on how we might attack this in the future (and should!) see [Split Storybook CLI](https://www.notion.so/Split-Storybook-CLI-6b0c06985bb54dfcbd2ddfe8da860df8?pvs=21).
• Deprecate internal APIs. Public APIs that should be internal will be deprecated, to be removed in SB9. Update docs to refer to new APIs (as needed, probably very minor). This will happen in a separate project (probably SB9).
• Deprecate public packages. This will happen later as part of the lead up to 9.0

Implementation

Must Haves

• Core package. Storybook’s core package are consolidated into a single package, @storybook/core. It will contain and expose all of the functionality of the packages it subsumes.
• Shim packages. Each subsumed package will be hollowed out and re-export functionality from core, so that this is a non-breaking change in 8.x. Each package will have its own deprecation message, linking to a general docs page, to discourage public use.
• Refactor non-core monorepo packages. Non-core packages, such as renderers/frameworks/addons will be refactored to depend on the core.
• Addon developer updates. addon-kit and addon authoring documentation should be updated to use the core. It should be made clear that this will create addons for 8.x and above (where x is the minor we release this change in). An addon migration guide for existing addon authors to adapt to these changes.

Variable scope

• Prebundling. We should take a first pass at prebundling core package dependencies to reduce install size & count. This could also be a small batch project for later.

Prior Art

We have done this kind of shimming before in 8.0 where we consolidated various packages into the manager-api and preview-api packages. This is a more extreme version of that.

Deliverables

See implementation section above

Risks

Because this involves moving lots of code, there are risks of:

• Unintentional breaking changes because we forget to re-export APIs. Fortunately these are easily fixed.
• Removing lightweight APIs that are meant to stand alone. We should do a careful audit of the consolidation before we release it.

Unresolved Questions

No response

Alternatives considered / Abandoned Ideas

No response