[core] Improve imports from the core monorepo #10418
Conversation
|
Deploy preview: https://deploy-preview-10418--material-ui-x.netlify.app/ |
6065124
to
b4ae149
Compare
| import MarkdownDocs from '@mui/monorepo/docs/src/modules/components/MarkdownDocs'; | ||
| import MarkdownDocs from 'docs/src/modules/components/MarkdownDocs'; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
The @mui/... to local ./packages are the required ones:
There was a problem hiding this comment.
I'm not following you
| import MarkdownDocs from '@mui/monorepo/docs/src/modules/components/MarkdownDocs'; | ||
| import MarkdownDocs from 'docs/src/modules/components/MarkdownDocs'; |
There was a problem hiding this comment.
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)
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
96f9a5d
to
3e0cc6e
Compare
3e0cc6e
to
d570ed3
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Closing because a lot of things changed in the infra since I opened this PR |
The only imports from
@mui/monorepoleft are@mui/monorepo/testI would like move utils on the core repo to an internal package
@mui-internal/test-utilities