chore: Dependency management RFC

[devongovett]

View Rendered RFC

Related discussions:

• Spectrum component dependency issues #2195
• Individual packages for `react-aria-components` #6734
• Components Import #7766
• @react-aria/utils 3.30.0 introduced breaking change #8635
• Make internal package references strict (or peer dependencies) #8777
• Improve performance for cases when React Spectrum is loaded at a runtime #8707
• Unmanageable dependency versions - Proposal: make react-aria and react-stately truly monolith. #7946
• Pin dependency versions on release #6326
• What's the correct way to handle packages version #7675

[vezaynk]

The above changes mean that a significantly smaller number of dependencies will be installed when using react-aria-components and @react-spectrum/s2. These will be the remaining packages:

react-stately
react-aria
@internationalized/*
react-aria-components
@adobe/react-spectrum
@react-spectrum/s2

Inter-dependencies between these packages should have pinned versions. Duplication could still occur if different parts of an application depend on different versions, but the likelihood is significantly reduced. It will also be much easier to resolve when it occurs because there are fewer packages to coordinate.

My understanding is that for at least some of these (looking at react-stately in particular), version duplication wouldn't be a problem.

For everything else, I think we could see even less duplication by declaring them as peers with pinned versions.

If they are regular dependencies, then a consumer depending on both react-aria-components and react-aria needs to be careful what versions they specify because mistakes will lead to silent duplication, whereas with peer dependencies, the issue will be more visible.

[snow893]

@devongovett With this change, we'll no longer need to add alpha/beta components as a dependency, right? Direct path should work as long as we have the correct monopackage dependency?

[devongovett]

@vezaynk Yeah peer dependencies are a possibility, but it would add a bit of friction to the installation process at least with certain package managers. You'd need to manually install react-aria and react-stately into your project in addition to react-aria-components, even if you weren't using them directly. Also adding peer dependencies is generally a breaking change, so it would be harder to keep backward compatible.

Another possibility I mentioned in the RFC is merging all of those into a single mega-package, which would make using the hooks and components together easier as well. But this is a bit bigger of a change that perhaps we'd consider separately in the future.

@snow893 Correct, the alpha/beta components would be included in the mono-package with the UNSTABLE_ prefix.

[mryechkin]

Love the proposal 🎉 Was never a fan of the individual packages approach - this makes a lot more sense to me. Hope to see it implemented.

[nwidynski]

@devongovett One downside of this will be harder visibility of cross dependencies being introduced, as they will no longer appear in package.json diff. Do you plan to maintain equal strictness on dependencies between sub-exports?

FYI, we have most of what this RFC proposes implemented in our fork, and it definitely delivered an improvement for bundle size of downstream applications 👍

[devongovett]

@nwidynski what do you mean by cross-dependencies?

[nwidynski]

@devongovett @react-aria/selection importing @react-aria/utils currently leads to @react-aria/utils being listed in its dependencies. Now with this RFC for example, adding an import from react-aria/collections to useSelectableCollection will not lead to a package.json diff anymore so its harder to catch.

I know some work has gone into containing features to specific packages (e.g. collection ids), so im basically wondering whether that will be maintained or dropped. In some cases this isolation would be great to get rid of, but im afraid this could negatively affect bundle size.

[devongovett]

@nwidynski the cross-package dependencies are more problematic because they can break due to multiple versions being installed, or breaking changes between versions. With everything in the same package that risk will become zero. As for bundle size, it should be reduced by usage of sub-path exports which are more reliable than tree shaking. The imports could even be more granular than the current package boundaries for example.

[devongovett]

Thanks for the feedback everyone! We're going to move forward with this approach. We'll start implementation soon and provide early builds that you can test in your projects as we go. Feel free to continue the discussion here if there is additional feedback.