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

[literalpie]

This allows for tree shaking, but not bundle splitting (I expect if you have an app with dynamic imports for bundle splitting, the first time you use any aria component in your app, it will load all aria components you use anywhere in your app). Has it been considered to use multiple entry points within the published package? I think this would give the benefit of code-splitting without as much maintenance burden for you, or the peer dependency issues.

[devongovett]

Might depend on your bundler, but I believe code splitting should work too. The bundler should follow the re-exports in the index.js file to the file where the component is defined, and include that in the appropriate bundle. I believe most bundlers support this. Parcel and Rollup definitely do, and I believe webpack does too.

[literalpie]

My bad, you're right. My message above was based on some bad experiences I've had with packages that didn't include "sideEffects": false. I just confirmed with some simple tests in rollup and webpack that this isn't a problem in other cases.

I think the other issue with the single entry point is development tools like Vite that don't do shaking/splitting optimizations (unless I'm wrong about that too :-P).

[Tiberriver256]

I'm pretty sure I'm running into a problem that might demonstrate the need for separate entry points.

I'm building a design system using react aria components and the timing of my jest tests is odd. Every test looks something like this:

The timing of the file is much larger than the sum of the individual tests.

I profiled it using 0x and the generated flamegraph showed jest parsing modules during its startup that I wasn't importing like breadcrumbs/links/etc. The same thing happens with bundling tools and such. It's not about bundle output size but how hard the CPU has to work to shrink that bundle size. So it's not something I'd put a very high priority on (i.e., compared to the end-user impact of not being able to tree-shake something) but for sure has the potential for impact on developer experience (i.e., build time and test time increase).

Probably the best talk I've been able to watch on what causes this and generally why barrel files are now considered more harmful than helpful is here:
https://x.com/_developit/status/1842225012092104732

The biggest changes might be:

1. Add a new optional direct import entry point to your package.json

Something like:

  "exports": {
    ".": {
      "types": "./dist/types.d.ts",
      "import": "./dist/import.mjs",
      "require": "./dist/main.js"
    },
    "./i18n": {
      "types": "./i18n/index.d.ts",
      "import": "./i18n/index.mjs",
      "require": "./i18n/index.js"
    },
    "./i18n/*": {
      "types": "./i18n/lang.d.ts",
      "import": "./i18n/*.mjs",
      "require": "./i18n/*.js"
    },
+    "./direct/*": {
+     "types": "./dist/types.d.ts",
+     "import": "./dist/*.mjs",
+      "require": "./dist/*.js"
+   }
  },

2. Change components that are internally importing from barrel-file module react-aria to doing direct imports from the @react-aria/* module

Something like:

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

A cursory glance through the components seems like some of them are direct and others go through the react-aria barrel file.