Individual packages for react-aria-components

[fellipeutaka]

Hi React Aria Team,

First, I would like to thank you for your incredible work on the React Aria library. Your dedication to providing accessible components and hooks is highly appreciated by the community.

Recently, I noticed the release of the new component-based library, which is a fantastic addition to the React Aria ecosystem. However, I have a concern regarding the structure of this new library. Currently, it is available as a single, large package.

One of the features I greatly appreciate in the hook-based library is the ability to install and import only the packages I need. For instance:

import { useButton } from 'react-aria';

import { useButton } from '@react-aria/button';

This modular approach allows for more efficient bundle sizes and reduces the overhead of unused code in my projects. In comparison, the new component-based library is only available as a single package:

import { Button } from 'react-aria-components';

To improve flexibility and maintain the benefits of modularization, I would like to request the addition of separately installable packages for each component in the new library. This would allow developers to install and use only the specific components they need, similar to the existing hook-based library.

I believe this enhancement would be beneficial for many users, as it would enable better optimization of bundle sizes and promote more efficient usage of the library.

Thank you for considering this request. I look forward to your response and appreciate your continuous efforts in improving React Aria.

Best regards,
Utaka

[reidbarber]

Thanks for creating this discussion. We've decided to move in the direction of just having a monopackage going forward, as well as encouraging the use of the monopackages for our existing packages. Some reasons for this include:

• If your bundler does tree shaking, you shouldn't get any components that you don't use included in your build
• Less maintenance for consumers when upgrading (avoids issues with peer dependencies)
• Less issues with duplicate package versions getting installed (creates issues with React contexts)
• Better DX when adding new components to your project
• Less maintenance on our end for releases

[m0xAy]

@Tiberriver256 yep, that's my experience too (with barrel files) - I know some people like a single import statement, but it would be great to have the option like MUI does. I prefer not using barrel files due to the added waste of time building and testing - in a large codebase with lots of contributions each day, it all adds up to quite a lot. Yes tree-shaking means you can still ultimately ship less code, but if you're importing less code in the first place, then there is less code to figure out what to remove - and less start-up times for tests?

I don't think individual packages for each component is the way to go, but being able to import a module directly would be really helpful.

[manuelcoca]

Thanks for creating this discussion. We've decided to move in the direction of just having a monopackage going forward, as well as encouraging the use of the monopackages for our existing packages. Some reasons for this include:

• If your bundler does tree shaking, you shouldn't get any components that you don't use included in your build
• Less maintenance for consumers when upgrading (avoids issues with peer dependencies)
• Less issues with duplicate package versions getting installed (creates issues with React contexts)
• Better DX when adding new components to your project
• Less maintenance on our end for releases

Thanks for sharing your insights. I've been digging through the repo structure and noticed some interesting patterns around dependencies that I'd love to understand better and continue discussion:

1. I see React is marked as a peerDependency, but there are lots of direct dependencies between your packages. What's your thinking behind when to use peer deps vs regular deps vs keeping things internal?

2. What makes you split something into its own package rather than bundling it with existing ones? Just trying to understand the trade-offs you consider.

3. When you need to make breaking changes, how do you handle updating all the interconnected packages? Curious about your real-world experience managing this.

[snowystinger]

Probably the best overview to answer 2 and 3 I can give is https://github.com/adobe/react-spectrum/blob/main/rfcs/2019-v3-versioning.md

It should be noted that the Drawbacks section has proven to have significant overhead in managing dependencies, so with React Aria Components we've moved away from individual packages per component. The hook libraries are still built in the original way. So new pattern functionality there is still a new package.

One answer is to question 1 is:
Using React as a peer makes it easier for people to keep only one version of React.

We use dependencies on all of our own packages because it would be painful for people to need to know and supply every sub dependency.

For example, a simple Button uses
react-aria/utils
react-aria/focus
react-aria/interactions
react-aria/button
react-aria/live-announcer
react-aria/collections
progressbar
and this doesn't even include the types.

Most of these are non-obvious and we have 200+ published packages, so it would quickly make people's package.json unreadable.

[manuelcoca]

@snowystinger thanks, appreciate the explanation.

[devongovett]

We're considering providing sub-path exports for each component in addition to a barrel file, which should help with tools that don't tree shake. Please see the RFC, and feel free to leave feedback! #8797

[karlhorky]

For Next.js, using the experimental.optimizePackageImports option can help for improving the performance of the barrel files of React Spectrum and React Aria that @Tiberriver256 documented above:

next.config.ts

import type { NextConfig } from 'next';

const config: NextConfig = {
  experimental: {
    // Load only the necessary modules from packages using barrel files
    // - https://nextjs.org/docs/app/api-reference/config/next-config-js/optimizePackageImports
    // - https://vercel.com/blog/how-we-optimized-package-imports-in-next-js
    optimizePackageImports: [
      // - https://github.com/adobe/react-spectrum/discussions/6734#discussioncomment-13588097
      '@adobe/react-spectrum',
      'react-aria',
      'react-aria-components',
    ],
  },
};

export default config;