[test] Add yarn deduplicate step

[oliviertassinari]

One chunk of #37, copy & paste from the main repository.

[dtassone]

Do we really need that? Yarn already dedup...
Also by introducing this package, we would have a different setup from our users, hence they might see issues that we won't see due to this extra step in the package management 🤔

[oliviertassinari]

Yarn already dedup...

Does he? https://github.com/atlassian/yarn-deduplicate#why-is-this-necessary. Proof: mui/material-ui-pickers#2036.

Do we really need that?

It's important for: avoiding types duplication and wrong version resolutions, bundle bloat by duplicated version. @eps1lon anything else?

we would have a different setup from our users

What issues do you have in mind? We should already design knowing Material-UI can be included twice in a bundle. It would also be better to have a dedicated test case for it if we want to give it a lot of weight.

[eps1lon]

@eps1lon anything else?

Keeping install size/time low. Every package adds a bit of size(=time) and in the npm ecosystem this actually results in a death by thousand cuts.

Ideally we'd autofix it but for human PRs I'd rather not let bots commit branches. For dependabot PRs we should. I do this on some of my repos which worked quite nice. Now that GH actions are public I should revisit that since human time > machine time.

Do we really need that? Yarn already dedup...

It does when installing but if you have a lockfile then every package manager makes sure that unrelated dependencies are not changed (i.e. deduped). So if you have A -> B -> Dependency, A -> Dependency and bump A/Dependency you don't want to bump A/B/Dependency since you didn't declare that you also want to change B. This is because dependencies are not part of you public API. It doesn't matter that B depends on Dependency. That is the implementation not the interface.

[dtassone]

avoiding types duplication, and wrong version resolutions

Yes and that can happen if we mismanage our versions, which can create issues on our local if we have duplicated types.

If one of the x-grid-modules installed package is duplicated for any reason, this extra step will delete the extra package.
But yarn or npm won't do it natively for our users. So it will leave us not understanding the bug our users are facing as we won't have the same setup.

[oliviertassinari]

@dtassone I personally don't recall seeing a GitHub issue report coming from such a problem. We have one similar case not directly related, but coming from one of our singletons with @material-ui/styles (we solved it by encouraging peer dependencies on core). I don't think that there is any downside to the change. I have a high confidence rate that this potential issue won't cause us any problem, that: developers are more likely to report the issue than we are to catch it with our repository. If it doesn't, we can point back to my comment at how I was wrong and you were right :). It's not like we are going to have a lot of dependencies anyway, considering you don't want to depend on clsx but bundle it :p.