[core] Use common copy-files script

[eps1lon]

🙌

copy-files is currently duplicated for every package that uses this logic with >99% overlap. This PR merges every single script into a common one. It helps refactoring build behavior (cumbersome for #13391 but will be easy with this change for e.g. #14392 if accepted) and brings some features to older packages such as:

• adds typings field to every published package (core, docs, lab, system, utils)
  • Helps sites like https://www.pikapkg.com to detect that types are bundled
• applies [core] Improve tree-shakeability #13391 to @material-ui/docs
• publishes types for @material-ui/icons/utils/createSVGIcon (includes /es build)
• adds license header to icons and utils esm index barrel
• publishes CHANGELOG.md to every package

Every single one of these points was done for one @material-ui/core

Fixes:

• fixes docs and lab module entry pointing to wrong file (caused by [core] Improve tree-shakeability #13391)

[oliviertassinari]

This pull request made me laugh. It's ridiculous from my part. I should have done this effort a long time ago instead of duplicating the script. Great move!

[oliviertassinari]

We were using babel-node so we could write the source with es modules. I'm curious why you want to change this point.

[eps1lon]

babel-node:

• imposes a runtime overhead
• makes debugging harder if sourcemaps are not setup properly

it enables in our case:

• es modules which don't provide any value in the node runtime

[oliviertassinari]

My motivation was more: let's write the same code everywhere even if it's not the best tool for the job. The difference is negligeable. Simplicity first.

I didn't know about the source map issue.

[eps1lon]

Let's defer this to a different PR then. I'll change to babel-node tomorrow.

I would like to get rid of it completely. Since node 8 already has async/await it doesn't add any value at the moment.

[oliviertassinari]

In some way, we might always need Babel. The JavaScript language is moving. Won't we need it too if we start using TypeScript?

[eps1lon]

Browser and node are two different targets. We use our node scripts only internally so requiring something like node 10 or 12 is not that big of a deal. Doing so removes the babel requirement apart from the latest es features and there is no big value gained by using those features.

Typescript for our node scripts is somewhat overkill at the moment. I think you're mixing various concepts here: babel-node has nothing to with our components (or Ssr). It's currently only used to use es modules in our node scripts that provide no benefit in the node runtime.

[eps1lon]

Tried to revert but babel-node has some issues with transpiling code that is outside the cwd which is common in a monorepo: babel/babel#7566

This is fixable with the ignore flag but then we have to maintain those contents for every require and TL;DR: The amount of maintenance and time this adds to enable es modules in the node runtime (which don't add anything) is not worth it. At least it hasn't been shown to me.

We can revisit this once we need to transpile this dev script at runtime.

[oliviertassinari]

I have revisited a bit the implementation. Let me know what you think.

[oliviertassinari]

We had an issue with yarn lerna run build:copy-files.

[eps1lon]

Do with the PR as you please. I can't work on this if you refuse to provide a rationale.

[oliviertassinari]

@eps1lon The rationale was highlighted in #14406 (comment). Now, the difference between babel-node vs using node doesn't outweigh the benefit of letting you pick what you think work best for the use case. I have reverted the changes. I have focused my attention on the logic, migrating some of the logic to the async / await syntax. I shouldn't have pushed force on your fork branch. I'm sorry. I'm happy to have looked at the code, the release script is important, better have more than one people having a close look at it. Eventually, we will release v4.0.0-alpha.0. People will report any problem.
Well done.