Unmanageable dependency versions - Proposal: make react-aria and react-stately truly monolith.

[alirezamirian]

Provide your feedback here.

We have implemented our design system based on @react-aria/* @react-stately/* packages, and it's been great how we can delegate the heavy lifting of accessibility and functionality of components to these packages, focusing on our design. What has not been working great for us though is the complicated interdependencies of packages and how little control we have over what we depend on.
Several cases of past releases broke our library, and the worst part is there is no way for us to ensure we get a chance to fix potential issues before they hit our users. That's because even if we set the dependency version of @react-aria/* packages to exact versions, the interdependencies of @react-aria/* and @react-stately/* packages still request a wide range (using ^). E.g. my-lib -> @react-aria/tooltip@a.b.c -> @react-aria/interactions@^x.y.z will bring in the latest version of @react-aria/interactions in a new installation of my-lib. Using the react-aria monolith package also doesn't change anything.

See also:
#7675 #2195

Proposal

I'm aware of your motivations for having a granular packaging for react-spectrum, and I understand you don't want to pin the version of interdependencies to a single version to make the shared dependencies dedupe-able. But for react-aria and react-stately monolith packages, would you consider eliminating the dependencies and exporting everything from source? That would greatly reduce the entropy and give more control to component libraries. That way:

• There won't be a need for deduping at all. Right now we have a script that detects duplicate installations of @react-aria packages, and instructs on how to deduplicate them, as it's not always practical in big monorepo workspaces to deduplicate everything.
• Changes like refactor: No longer preventDefault in usePress and allow browser to manage focus #7542 that touch many packages will be less likely to breach semver for users of the monolith package. And even if they do break something in libraries depending on react-aria, it will be possible to have a chance of testing the upgrade and making potentially needed changes, by choosing the more cautious path of depending on exact version and upgrading regularly.

I know it's not as simple as changing react-aria's index.ts to export from source, but how about changing the build configuration for react-aria and react-stately monolith packages to inline and emit the dependencies rather than externalizing them?

🔦 Context

We have hundreds of frontend apps depending on our design system library that's implemented using @react-aria and @react-stately packages and with most of the past react-spectrum releases there has been something that broke our components. With the way those dependencies depend on each other, our end users are directly affected by react spectrum releases, rather than us being able to upgrade, test and release new versions.

💻 Code Sample

No response

Version

No response

What browsers are you seeing the problem on?

No response

If other, please specify

No response

What operating system are you using?

No response

[devongovett]

Wouldn't that result in the same problem described in #6326 (comment)? Then if you mixed the react-aria package with an individual package like @react-aria/button you'd get duplicates. You might not intend to do this or even realize if a third party library uses an individual package as a dependency.

I'd say if we did this we'd need to do it in a major version, and deprecate the individual packages at the same time.

[snowystinger]

Linking in another related discussion #7909 (comment)

[alirezamirian]

@devongovett true, the interoperability of libraries that use the monolith package and the ones that use the individual packages will be affected by such a change. Maybe I'm biased based on the use cases I've seen but it's weighed less in my head, compared to the issues mentioned above. A constraint that disallows a mix of react-aria and @react-aria/* packages would be less limiting in practice than the current state which:

• Requires the users of any react-aria-based library to manually and regularly deduplicate
• The deduplication is not always guaranteed, and depends on the version ranges of react-aria deps in those libraries.
• Even with 100% deduplication, there is still a chance that an older version of a library stops working after a react aria release.

You could also just deprecate the individual packages as you said and go for a single package. I'd be happy to contribute by a migration codemod for projects that use the individual packages.

The current structure (/interactions, /selection, /focus, etc.) is indeed a nice modular structure, but maybe it doesn't mean those should be versioned separately. With package.json exports becoming widely supported now, they can be different entrypoints of a single package. And that makes it much more manageable to make sure semver is fully followed.

[devongovett]

Yeah, I agree with you in theory. That's why we went to a single package for react-aria-components. We could probably move more in that direction, but it would need to be done in a major version I think.

One downside is that lots of other libraries use just one small part of React Aria. For example, Tailwind's Headless UI project uses @react-aria/interactions. If we deprecated this, it would mean they'd have to install a much larger dependency. Not sure what the right approach is there.

[alirezamirian]

Sharing another case of this issue that hit us after the recent release (8 hours ago):
We had a dependency to react-aria-components@1.10.1 which uses unstable API from @react-aria/utils. The UNSTABLE_ prefix was removed in @react-aria/utils@3.30.0, breaking react-aria-components@1.10.1 because its dependency to @react-aria/utils is broad enough to allow for v3.30.0.

[TheCodeDestroyer]

Maybe I am missing something I read this and Im not sure I get it.

If you used workspace:* versions instead and then changesets for easier dependency release management. And lets say you change package A, wouldnt changesets pickup all libs that use package A as a dep and propose a new release for all of those?

[snowystinger]

workspace:* or workspace:^* is only for inside the mono repo.

We're referring to installs outside, in someone's app, where they might have a dependency directly on one of our packages (packA), at say packA: 3.42.0.
But they may also have a transitive dependency on one of our packages through pack3rdParty->packA: 3.43

Now lets say that packA has a dependency on packB. If that dependency is a range, then one copy will satisfy both of them, the highest one.
packA: 3.42.0 depends on packB ^1.0.0
packA: 3.43.0 depends on packB ^1.0.1
packB 1.0.1 will work

However, if it is not a range, then two copies at different versions must be installed to satisfy each dependency.
packA: 3.42.0 depends on packB 1.0.0
packA: 3.43.0 depends on packB 1.0.1
packB 1.0.1 and packB 1.0.0 will both be installed

Let us know if that makes more sense. We know it's a tricky situation made worse by packages managers meant for managing node packages more than browser client packages where a duplicate package like this wouldn't be such a big deal.

[TheCodeDestroyer]

workspace:* and workspace:^* both get resolved to current version of the package when packing up the lib.

Regarding your example isnt this a potential issue if packA v3.42.0 only works with v1.0.0 and not v1.0.1? I am a user of HeroUI (previously NextUI), which uses RA under the hood and there are a lot of issues that keep resurfacing because sub-dependencies are not locked.
TBH I dont see an issue if user installs both packB versions in which case each installs its own packA if users want to prevent that afaik they can solve the issue via overrides if it bothers them and they really need two packB versions installed.

[snowystinger]

workspace:* and workspace:^* both get resolved to current version of the package when packing up the lib.

Right, we have a script that already does this essentially. It's from before this syntax existed and we just haven't moved off of it yet. But they are equivalent.

Regarding your example isnt this a potential issue if packA v3.42.0 only works with v1.0.0 and not v1.0.1? I

Right, this is the crux of the issue The UNSTABLE_ prefix was removed in @react-aria/utils@3.30.0, breaking react-aria-components@1.10.1 because its dependency to @react-aria/utils is broad enough to allow for v3.30.0. We didn't think of the removal of UNSTABLE as breaking, though there are some compelling counter examples now that are causing us to discuss that assumption.

TBH I dont see an issue if user installs both packB versions

This one is really tricky and presents itself in a variety of ways. One issue is React Context, which is an identity match since React 16, not a string match like it used to be. So if you have two copies of a Context as a result of installing the same module twice, anything relying on that Context may not work. And we have a lot of Context use, it's pretty much what our API for React Aria Components is built on. React itself really works best if there is only one copy on the page.

It extends beyond Context though, anything that is meant to be a Manager or Singleton, ie FocusScope, ariaHideOutside, usePress, etc will fight with the other copies of itself in unexpected ways.

[TheCodeDestroyer]

Then I guess the only way to solve the issue would be to create a megapack lib that includes all libs with fixed versions (what the initial issue author suggested)?

[devongovett]

Hey everyone, we're considering implementing this change to merge all code into a single package instead of re-exporting from individual packages. It will be backward compatible. Please see the RFC, and feel free to leave feedback! #8797