Fix JavaScript Webpack tree-shaking

[aduth]

🛠 Summary of changes

Fixes an issue where Webpack tree-shaking (dead code elimination) was not working, inflating the size of JavaScript bundles by including JavaScript for design system components not in use.

This appears to have regressed as part of the revisions to conditionNames in #8655, though it's not entirely clear to me the relation between conditionNames and tree-shaking, aside from the net result that Webpack was choosing to resolve to CommonJS over ESM. Experimenting with ordering of conditionNames did not yield a desired outcome, but it does work correctly using the ... placeholder found in Webpack's internal source.

Performance Impact:

NODE_ENV=production yarn build && ls public/packs/js/application-*.js | head -n 1 | xargs brotli-size

Before: 17.3kb
After: 1.76kb
Diff: -15.54kb (-89.8%)

📜 Testing Plan

NODE_ENV=production yarn build

Observe that the application-[digest].js bundle in public/packs/js does not contain references to character-count.

Verify no regressions in expected behavior of #8655.

[allthesignals]

I'm curious whether this ... is "public" behavior (can we rely on it during minor/patch bumps). The pattern seems documented in other Webpack features. 🤷

[aduth]

I'm curious whether this ... is "public" behavior (can we rely on it during minor/patch bumps). The pattern seems documented in other Webpack features. 🤷

Hmm, yeah, that's interesting re: the documentation in other options. I would hope that would mean it's at least intended to be supported, just not documented? I could also check if there's anything in their specs referencing it as something to not be regressed.

I'd hope in the worst case it'd be pretty obvious for us if it breaks if everything stops resolving all of a sudden during a Webpack build 😅

[allthesignals]

I'm curious whether this ... is "public" behavior (can we rely on it during minor/patch bumps). The pattern seems documented in other Webpack features. 🤷

Hmm, yeah, that's interesting re: the documentation in other options. I would hope that would mean it's at least intended to be supported, just not documented? I could also check if there's anything in their specs referencing it as something to not be regressed.

I'd hope in the worst case it'd be pretty obvious for us if it breaks if everything stops resolving all of a sudden during a Webpack build 😅

There seem to be some examples that do but I don't know whether they're asserted for!

FWIW I've also seen some libraries enforce bundle size checks to make sure tree-shaking still works which could be useful here.

[aduth]

FWIW I've also seen some libraries enforce bundle size checks to make sure tree-shaking still works which could be useful here.

I like that idea. As things stand, it's a little too easy for this to regress and go unnoticed.

[aduth]

FWIW I've also seen some libraries enforce bundle size checks to make sure tree-shaking still works which could be useful here.

I like that idea. As things stand, it's a little too easy for this to regress and go unnoticed.

Done in #9353