Modernize Babel config

[hasparus]

Describe the bug

We compile too much.
Have you seen how the output looks like?

Wow.

We use @babel/preset-env with no options, what's discouraged in @babel/preset-env docs.

We could go with something like this

    [
      '@babel/preset-env',
      {
        bugfixes: true,
        loose: true,
        modules: false,
        targets: '> 0.25%, not dead, not ie 11, not op_mini all',
      },
    ],

The bundle size difference on @theme-ui/color-modes is 6kb unbundled. (~15kb to ~9kb)

However, this is a breaking change...

A non-breaking move forward would be enabling loose transformations with loose: true. See #1721.

cc @lachlanjc @fcisio @flo-sch what do you think, folks?

[johno]

Hey folks! I'm more an interested bystander at this point, but I'd love to see this land as a single breaking change in an 0.9. It's technically breaking but shouldn't affect most tooling pipelines unless there's unorthodox legacy browser support. It could be a pretty seamless upgrade and shave off the bundle shipped over the pipe and substantially less JS for parsing.

(we've been looking into Theme UI performance for Components AI since it drives most of our app and this is a low-hanging fruit we've found, plan on reporting back and proposing upstream improvements in the future)

[flo-sch]

Becoming less compatible than React and Emotion could be considered bold, but I am kinda keen on helping the world move away from old, inefficient and potentially unsafe browsers... (even though one could argue it is not theme-ui's role)

AFAIK as a worse case scenario, if you use a bundler, you should have a workaround to re-transpile some node_modules to your needs, right?

(Or should we add a CI extra "legacy" build target that you could opt-in if you really need it? 🤔)

[lachlanjc]

I'm in favor!

@johno — I'd be super curious to see your other findings!

[hasparus]

PR #1721 addressing this has been merged to develop.