-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] Explicitly define package dependencies #38859
Conversation
0c4acfa
to
10bac2a
Compare
Netlify deploy previewhttps://deploy-preview-38859--material-ui.netlify.app/ Bundle size reportDetails of bundle changes (Toolpad) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not reading every line, but 👍 on the methodology.
For the record, I used depcheck to analyze what's missing and what's redundant. It required some manual adjustments afterward, but the passing build and tests should be a good indication that it works. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"@types/node": "^18.17.6", | ||
"@types/prop-types": "^15.7.5", | ||
"@types/react": "^18.2.21", | ||
"@types/react-dom": "18.2.7", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see a lot more installation warnings (yarn)
We've got more dependencies now, so it's expected that the same errors will appear in more places, where the dependencies are defined.
However, some of them look like false positives (react as peer dependency). I'll see what I can do about them.
Can we fix all these?
pnpm doesn't report these, so we should be good after we switch to it.
why is @types/react not set only once in the root package.json workspace
Because it's used by individual packages, not just the scripts at the workspace root.
How about we move all the @types dependencies of docs to be devDependencies?
Yup, types should be in dev dependencies. I'll fix it (#38914)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However, some of them look like false positives (react as peer dependency). I'll see what I can do about them.
👍 Many of them are top-level packages that define react as a peer dependency, but we don't have react as a workspace root dependency, so there is no strong guarantee about which version of react ends up adjacent to them in the node_modules folder. Just installing react
and react-dom
as a dev dependency in the root should solve a lot of these false positives.
The others that complain about incompatible react version are more problematic. These may work now, but as the authors don't guarantee compatibility with React 18, technically there may be breaking changes introduced for these packages on minor React versions.
edit: I opened a quick notion page to document our strategy towards getting rid of all these warnings. But perhaps a GitHub issue makes more sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pnpm doesn't report these, so we should be good after we switch to it.
Ah, ok, great.
Because it's used by individual packages, not just the scripts at the workspace root.
OK, but it feels better DX to have the common dev dependencies defined only once at the root of the workspace and to only define the ones that can't upgrade just yet to stay on an older version in the sub package.json (it's less duplication). Is this a pnpm limitation that yarn doesn't have?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, pnpm requires packages to be defined where they are used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this should work, but why would you want to treat @types/react differently than the rest of the dependencies? Versions are handled by renovate anyway, so updating in individual packages is as easy as in workspace root.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but why would you want to treat @types/react differently than the rest of the dependencies?
I agree, my strictly personal preference would also be to be explicit in declaring all dependencies per workspace. It makes the workspaces more self-contained. But I don't think in our current situation there is much practical benefit of one method over the other so either way is fine for me.
forcing a default of sharing the same version while keeping flexibility
For reference, pnpm
has an RFC that should help with enforcing a single version across all workspaces. There also seems to be an intent to implement.
edit: @michaldudak seeing this RFC reminds me that it probably makes sense to take pnpm-workspaces.yaml
into account for calculating the pnpm
cache key in CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, my strictly personal preference would also be to be explicit in declaring all dependencies per workspace. It makes the workspaces more self-contained.
What's the value of having the dev dependencies that are used in, say 80% of the codebase, to be defined in each workspace (where used)?
I'm blind to the value, the closest I can understand would be allowing us to move from yarn to pnpm to have faster npm install, otherwise I don't understand, I'm missing something. I fear for the problems it creates, e.g. #38920 (comment) or the RFC motivation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm blind to the value
That's why I call it a strictly personal preference. I enjoy the idea that when I can copy a workspace folder to my desktop and run yarn
inside of it and everything just works it's a sign of true encapsulation. Meaning the workspace function is to link packages together and nothing else and all other code sharing between packages happens through explicit dependencies.
But truely personal preference in my opinion, the monorepo has much more important issues than this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seeing this RFC reminds me that it probably makes sense to take pnpm-workspaces.yaml into account for calculating the pnpm cache key in CI.
@Janpot, for now, I followed the official guidelines about setting up the cache. When the catalogs are introduced, we'll have to adjust our setup anyway, so then we can add the workspace definition to the cache key.
@@ -41,7 +41,17 @@ | |||
"@babel/runtime": "^7.22.10", | |||
"@emotion/cache": "^11.11.0", | |||
"csstype": "^3.1.2", | |||
"prop-types": "^15.8.1" | |||
"prop-types": "^15.8.1", | |||
"react": "^18.2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure that we need react
(!!!) in @mui/styled-engine
dependencies?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @michaldudak
"prop-types": "^15.8.1" | ||
"csstype": "^3.1.2", | ||
"prop-types": "^15.8.1", | ||
"react": "^18.2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shoudn't be here
"react": "^18.2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, this should either have been defined on the workspace root, or it should have been a dev dependency
@Semigradsky, @oliviertassinari, fixed in #38971 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for good measure, I did go through it a bit more thoroughly. Left two minor comments.
@@ -9,7 +9,8 @@ | |||
}, | |||
"devDependencies": { | |||
"@types/eslint": "^8.44.2", | |||
"@typescript-eslint/parser": "^6.4.1" | |||
"@typescript-eslint/parser": "^6.4.1", | |||
"eslint": "^8.47.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this (technically) also be a peer dependency? It's an eslint
plugin after all.
}, | ||
"peerDependencies": { | ||
"@types/react": "^17.0.0 || ^18.0.0", | ||
"react": "^17.0.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you aware of incompatibilities of this package with react 18? I think it's the only peer dependency conflict we experience on Toolpad. We import it for the docs. afaik our docs are on React 18, and this doesn't seem to be breaking them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Toolpad docs don't directly depend on it, but we can't remove it yet: mui/toolpad#2684.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I've tried the same before 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you aware of incompatibilities of this package with react 18?
@mnajdova would likely know the best.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you aware of incompatibilities of this package with react 18?
One issue is GlobalStyle injection that is called twice in React 18 so not removed after unmounting.
Extracted from #36287
In this PR, I listed all the dependencies in package.json files. This is not required by yarn (but it's a good practice anyway), but pnpm needs it.
Additionally, I standardized the layout of package.json files (order of fields).