[core] Hoist duplicated dependencies

[oliviertassinari]

Prevent the versions to be different, it forces to upgrade all at once.

[oliviertassinari]

@dtassone Should I rebase?

[dtassone]

this package does not exist anymore.

[oliviertassinari]

Definitely, it's outdated:

Are you happy with me pushing in the hoisting direction? #341 (comment)

[dtassone]

I think that yarn hoist the package automatically in workspaces or monorepos to root folder of the repo, unless pkgs contains different versions... So keeping the same version of pkgs is better as it avoids nested node_modules.
However removing the dev dependencies of each package is not that great as it makes it less obvious to understand what each package needs and what are their real dependencies. Also if we decide to move the package outside this repo then we would have to rebuild each package.json
Lastly in the root package.json we can easily end up with a bunch of dependencies that we won't know if they are being used by any of the nested packages.

[oliviertassinari]

The arguments I see in favor:

• Force to have a single version for the whole repository, no mess to manage between inconsistent versions
• If we don't hoist http://dependabot.com/ will update each version for each package individually.

[oliviertassinari]

less obvious to understand what each package needs and what are their real dependencies.

I think we can solve by having a single script command that all the packages use. It's what we do in the main repo and very likely what we want to do it here too so when we change something, we change it for all the packages at once. So I think it puts us in the right direction.

if we decide to move the package outside this repo then we would have to rebuild each package.json

It would only happen if we move it to mui-org/material-ui, where the same packages should be available with the latest version. So, I think that it's a good thing, it will help catch inconsistencies.

Lastly in the root package.json we can easily end up with a bunch of dependencies that we won't know if they are being used by any of the nested packages.

Probably true for any packages, there is only a tight link between the usage and its declaration. But yes, the fewer LOCs the simpler its to find dead dependencies. IMHO, the best answer to this is to be rigorous when deleting code and second guessing dependencies upgrade PRs.