[core] Improve imports from the core monorepo

[flaviendelangle]

The only imports from @mui/monorepo left are @mui/monorepo/test
I would like move utils on the core repo to an internal package @mui-internal/test-utilities

[mui-bot]

Deploy preview: https://deploy-preview-10418--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 86db0bf

[romgrk]

I don't love this change, I feel like the @mui/... prefix was a nice way to indicate that it comes from another MUI package. It would be nice if we could have a standardized form to rename packages from the monorepo.

[LukasTy]

I feel like the existing docs and docsx approach is pretty well established in everyone's head, but I can also second this though, ideally, we should aim at using a similar approach to aliasing/naming all packages and currently docs, docsx and typescript-to-proptypes are probably the only exceptions. 🤔 🤷
This could become @mui/docs or @mui-internal/docs (although the former would be a better fit given how the alias names are chosen)

[flaviendelangle]

This could become @mui/docs

We already have this one but it's almost empty

I do agree that the current aliases are a mess.
But for me @mui/monorepo is not the solution.
I would prefer, as Lukas suggest to move the code on the doc to some @mui-internal packages.

[flaviendelangle]

For me the main pain of @mui/monorepo is that in theory anything on the core repo is "public API" because it's used by us, so anytime they break something, maybe we are impacted.

The idea of removing this alias eventually, is to make clear which folders in there repo is public API and which one they can totally rework without caring for others.

So once we are not using @mui/monorepo anymore, we can start cleaning the other aliases (move to the new @mui-internal nomenclature everywhere would be a good start).

And then we will be able to move those new @mui-internal packages to another repo if we want.

[romgrk]

Ok gotcha. I'm not sure how I feel about the non-required aliases overall, they do require getting used to. When I played with the babel config a few weeks ago I wasn't sure what was what. Non-magic stuff is easier for newcomers, and doesn't require engineers who update the configs to have as much accumulated knowledge of the project.

But I do see the benefits of @mui-internals, and if it was all standardized to that I would be reasonably happy.

Feel free to merge anyway, just wanted to voice my concerns.

[flaviendelangle]

What are you referring to when you talk about "non-required aliases" ?

My dream scenario would be that one day we have one repo for the infra with all the code published on NPM and versioned in well-defined packages.

[romgrk]

The @mui/... to local ./packages are the required ones:

[flaviendelangle]

I'm not following you

[LukasTy]

Nice cleanup overall! 👍

[LukasTy]

I feel like the existing docs and docsx approach is pretty well established in everyone's head, but I can also second this though, ideally, we should aim at using a similar approach to aliasing/naming all packages and currently docs, docsx and typescript-to-proptypes are probably the only exceptions. 🤔 🤷
This could become @mui/docs or @mui-internal/docs (although the former would be a better fit given how the alias names are chosen)

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[flaviendelangle]

Closing because a lot of things changed in the infra since I opened this PR