Create actual browser bundles and transpile everything else

[BinaryMuse]

Required reading: #779

This PR significantly changes up our bundling situation:

• Rollup now produces two actual bundles: dist/browser.esm.js and dist/browser.umd.js. These are actual browser bundles — all dependencies except for our peer dependencies (react and styled-components) are included in the bundle. These are really only useful for dropping onto a page with the appropriate ESM/UMD setup (e.g. the user is also including the peer deps). We may decide we don't even need these, but they may be useful for tracking deltas in size over time. Note: these files are quite large (500KB, even after minification), but include all the dependencies.
• Everything else gets transpiled directly from src/ into dist/. This will allow users to use both import {Box, BorderBox} from '@primer/components' and also import Box from '@primer/components/dist/Box'. This also enables import ShinyNewThing from '@primer/components/dist/experimental/ShinyNewThing'

Todo:

• If this is landing in 19.0.0, update the docs in Create actual browser bundles and transpile everything else #789 to include the new instructions.

Release Notes

• You can now import individual components without having to include the entire package or set up tree-shaking; for example, import {Box} from '@primer/components' can now also be written as import Box from '@primer/components/dist/Box'

Closes #779
Closes #456
Closes #797
Closes #801

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/primer/primer-components/ni2ajrvgh
✅ Preview: https://primer-components-git-mkt-bundle-up.primer.now.sh

[BinaryMuse]

Since this PR will make every component importable directly from its transpiled source file, each component's exports shape will be part of the public API of the package. As such, I'm proposing making that contract explicit in our tests:

checkExports('Position', {
  default: null,
  Position,
  Absolute,
  Fixed,
  Relative,
  Sticky
})

checkExports('Box', {
  default: Box
})

checkExports will ensure that the file at the given path exports the things we expect; if there are keys in the expected exports that don't match, or there are things exported that we don't expect to be exported, the test will fail.

Before I go through the entire codebase adding this, I wanted to get some feedback from the team to see how people felt about such a thing.

[BinaryMuse]

As I was looking through the exports, I noticed two modules where importing directly from the dist folder was a little weird: the Button variants and the Position variants. I've modified them as such:

• Button and variants can now be imported as:

  import Button, {
    ButtonDanger,
    ButtonPrimary,
    ButtonOutline,
    ButtonGroup,
    ButtonTableList
  } from '@primer/components/dist/Button'

• Position and variants can now be imported as:

  import Position, {
    Absolute,
    Fixed,
    Sticky,
    Relative
  } from '@primer/components/dist/Position'

Open to other thoughts on organization, and also curious the best way to go about documenting individual exports when the component isn't directly available on the default export.

[BinaryMuse]

With some more changes it's sitting at ~170KB.

[emplums]

I like the checkExports idea!

[emplums]

This looks great! might be helpful to have at least another person review this too since it's lots of changes!

[dmarcey]

I'm definitely not a rollup / babel expert, but I looked through the changes to try to give another set of 👀 and things looked good to me! Nice work! ✨

[T-Hugs]

Potentially a dumb question: Is there a real benefit to shipping bundles in the first place? How many consumers want a UMD module bundle? If the answer is "not really" could we just get rid of rollup completely and force consumers to use a bundler (because let's be honest, if you're writing frontend JS you're using a bundler).

[BinaryMuse]

Is there a real benefit to shipping bundles in the first place?

I don't think so, and in fact it's not documented. I think it's potentially useful for us internally for seeing how our package would behave if it was bundled; a good example is cutting off ~800KB off the minified library size based off the work in this PR.