-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
[code-infra] Change package manager to pnpm
#11875
Conversation
"tsx": "^4.7.0", | ||
"typescript": "^5.3.3", | ||
"typescript": "^5.4.5", |
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.
Had to bump to avoid problems with TS being unable to correctly resolve linked deps in a monorepo.
microsoft/TypeScript#42873 (comment)
@@ -8,9 +8,16 @@ | |||
"noEmit": false, | |||
"emitDeclarationOnly": true, | |||
"outDir": "build", | |||
"rootDir": "./src" | |||
"rootDir": "./src", | |||
"types": [ |
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 is great! Is there a reason to not place it directly in tsconfig.json
? I feel like it would be beneficial to keep the config for typechecking as close as possible to the one for type generation. This file should adopt the setting automatically through the extends
.
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.
If I understand correctly, two reasons
- for typechecking we use
noEmit: true
and for type generation we usenoEmit: false
. But I believe this should be achievable through a cli flag as well. - for type generation we're working towards a setup with a single compilation using project references instead of a compilation per project. But I hope we can bring this setup to type checking as well.
cc @michaldudak will be able to shed some more light, I may be a bit off on this.
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 I hope we can bring this setup to type checking as well.
This is already set up like this in the Base UI repo. However, it doesn't work perfectly (yet), as it doesn't typecheck tests.
for typechecking we use noEmit: true and for type generation we use noEmit: false. But I believe this should be achievable through a cli flag as well.
True. I believe all settings are available through commandline flag. It's a matter of readability to create a config file.
In addition to what @Janpot wrote, the build config also excludes tests from the output.
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.
Did you use corepack enable
to install pnpm
? Can you try that?
Otherwise, if you installed it separately, you may take a look at this issue and remove pnpm
from your PATH
variable and let corepack
take over.
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 installed using this script https://pnpm.io/8.x/installation#on-posix-systems
you may take a look at pnpm/pnpm#3016 (comment) and remove pnpm from your PATH variable and let corepack take over.
That didn't help, but sudo corepack enable pnpm
did, thanks!
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.
Looks good as far as I'm concerned!
Thanks for working on this! 🎉
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.
Great effort!
@@ -5,6 +5,9 @@ | |||
> Tip: For people who are doing the release for the first time, make sure you sign in to npm from the command line using security-key flow as well as have two-factor authentication enabled. | |||
> You can follow [this guide](https://docs.npmjs.com/accessing-npm-using-2fa) for more information on how to set it up. | |||
|
|||
> Tip: You can use `release:publish:dry-run` to test the release process without actually publishing the packages. |
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.
@michaldudak I've added a tip here to spread more knowledge as I wasn't aware of this option before working on this PR. 🙈
Closes #10658
CI runtime improvement
Before: ~20mins
After: ~16mins
Replicate the migrations already done on mui/material-ui#36287 and mui/toolpad#2546.
IMHO, this change https://github.com/mui/material-ui/pull/36287/files#diff-8ee0a5d567f55f7e7507f6cd79d9c37721906efe84f500acc89c551508c43464 deserves to be delivered via a separate PR to reduce the unwanted noise. 🤔
Progress
yarn
topnpm
eslint
happyproptypes
happytypescript
happybuild
happytest:unit
happytest:karma
happytest:e2e
happytest:regressions
happydocs:api
happyTested more or less all scripts, only
size:snapshot
andsize:why
do not work. But that's the case withyarn
as well. 🙈Build output comparison
There are 732 files with diffs (some of them expected - package.json) comparing the current build output with
yarn
and this branch.The most notable changes repeated in many files in most packages:
{}
instead ofObject.prototype
:reference
comments (i.e./// <reference types="@react-spring/shared" />
)jsx-runtime
imports.Note
This looks like a "bugfix" to me.
undefined
for optional fields, i.e.:Note
This is due to a bump of
typescript
. Bumping it onyarn
produces the same result.GridPremiumColumnMenu.d.ts
:Note
This is due to a bump of
typescript
. Bumping it onyarn
produces the same result.The exploration for ditching babel-loader (no longer relevant as the problem has been fixed in a different way):
babel
totsx
for test compilationdate-fns@v2
anddate-fns@v3
adapters on Pickers side and their testing implementation currently relies on hackily replacing imports on our predefined rules using a patched babel plugin.date-fns@v3
, but that doesn't work nicely, because the resolved version ofdate-fns
is still v2, because it comes (is used) from a dev dependency on@mui/x-date-pickers
event though this package specifies and resolves "date-fns": "^3.6.0". 🙈