[core] Fix transpilation target of UMD bundle

[eps1lon]

1. UMD bundle is not transpiled with the proper target (from .browserslistrc)
2. yarn test:karma issues warnings about imports not being resolved
   This is not severe since tests pass fine but is noisy

This was introduced in 4b71794#diff-09c56b2bf95de2a608a36afef3b6893146a959d6739be0a154dc9c9f02d80f24L7-R20 in order to let yarn workspace @material-ui/core build:umd pass. However, we can use existing patterns (use named imports over path imports) without having to change infra. Changing build infra is always scary since we don't (and likely never have) a proper coverage for that output.

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against eaef85c

[oliviertassinari]

The motivation was to allow:

import Slider from '@material-ui/core/Slider';

to be an effective way to tree-shake the bundle, even in development. If we move in this direction, I think that we might as well update the demos. We would load the whole unstyled package. it seems to yield the same properties with a nicer DX:

import { Slider } from '@material-ui/core';

I think that we should be careful with how it will scale. We can look at the icon for that.
Next.js renders the following page in less than 1s ✅.

import React from 'react';
import CloseIcon from '@material-ui/icons/Close';

export default function LandingPage() {
  return (
    <div>
      <CloseIcon />
    </div>
  );
}

However, If you take this demo, it takes ~60s for Next.js to render it ❌.

import React from 'react';
import { Close as CloseIcon } from '@material-ui/icons';

export default function LandingPage() {
  return (
    <div>
      <CloseIcon />
    </div>
  );
}

[eps1lon]

Let's focus on the concrete case not icons and deal with scaling issues after we actually scaled. See "YAGNI" and "don't optimize before you meassure".

[oliviertassinari]

Oh yeah, icons was probably not the best comparison I could have picked.

a.

import Alert from '@material-ui/core/Alert';

vs.

b.

import { Alert } from '@material-ui/core';

would have been a to more accurate considering that unstyled will have about the same amount of modules as core. It turns out that there isn't much difference in this Alert case (a. 1.9s vs. b. 6.22s), I mean, below 10s could be good enough.

I guess I was more concerned about what would happen if we x2 the number of components in the core. Would we start to hit a slowness?

[oliviertassinari]

@eps1lon Is this measurement better 🔼 :). Do you agree with the hypothesis that below 10s we are good and above it starts to be an issue (relative to the machine used)?

[eps1lon]

Let's get next in a good shape and then deal with reproducible issues later.