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/[email protected] -> @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.