[feat] Investigate pkg.module and bundler tools for better module support & tree shaking

[suzubara]

Does your feature request relate to a specific USWDS feature?
No

Is your feature request related to a problem? Please describe.
This is an optimization of the lib bundle size which can improve performance

Describe the solution you'd like
Investigate generating pkg.module with a bundler tool (e.g. rollup, esbuild, or adapt existing webpack). Create a PR implementing the suggested approach with a brief rationale.

Describe alternatives you've considered
We can choose to do nothing.

Additional context
Port from initial roadmap -- motivation behind this is to optimize the library exports for better performance & modern JS applications.

• https://github.com/rollup/rollup/wiki/pkg.module
• https://stackoverflow.com/questions/41289200/output-an-es-module-using-webpack

[jkjustjoshing]

@suzubara has any further thought been given to this since the ticket was created? I'd love to avoid pulling in several hundred more kb than I need of dependencies!

I was about to open a similar issue (glad I searched the open issues first!). Here are some thoughts/observations I have.

It doesn't seem like Webpack has great support for ES Module outputs. It also doesn't seem to easily output 2 parallel bundles (assuming we want to keep the CommonJS UMD output as well). There are 2 ways to solve this that I can think of:

1. Switch to Rollup (as you mention in the ticket title). The webpack.config.js file doesn't seem to be doing anything too complicated or unique, so rewriting it in Rollup would probably not be too challenging. (Storybook would still use webpack under-the-hood, but that's abstracted away from us).
2. Add a second build step with Rollup. Still generate index.js and uswds.css using Webpack, but then use Rollup to generate the index.esm.js file. This would get complicated/messy if the Javascript file depends on any of the other assets inside the ./lib folder, but from what I can tell the assets are only referenced by uswds.css, so this wouldn't be an issue.

Do you think the team is leaning more towards one or the other of those solutions? Is a PR for this something the team would be open to, or is it a large enough change that you'd need to dedicate more internal resources to it than you're able to right now?

[Morsey187]

I've had a quick look at using webpack V5 a while ago now, I managed to get it to output an ES6 module however it seems like this feature is very much experimental as it opened up a rabbit hole of issues trying to get the ES module to work with my Next.js build.

I'd like to iterate @jkjustjoshing 's queries above, and see if there would be any appetite in using rollup.js as the approach instead? I think either of his options sound fine. Otherwise I could have another look at the webpack changes I made previously and open a PR with some notes with the issues I encountered so others can take a look? The changes required for webpack were pretty minior, but it seems like a concerning route if webpack is likely to cause more issues down the line.

I'd also like to know what the current teams resourcing is like in terms of supporting a PR, or whether this issue is on your roadmap?

This would also be a great issue to solve from an environmental perspective, I'd imagine there are quite a few high traffic sites that could split their JavaScript bundles in half.

[lpsinger]

Did you consider esbuild as an alternative to rollup?

[jpandersen87]

I have a proof-of-concept of using vite/vitest here: #2716

[werdnanoslen]

Now that #2716 has been merged, what's the state of this issue?