-
Notifications
You must be signed in to change notification settings - Fork 654
feat: add support for pnpm catalogs #5467
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
base: main
Are you sure you want to change the base?
feat: add support for pnpm catalogs #5467
Conversation
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
libraries/rush-lib/src/logic/installManager/WorkspaceInstallManager.ts
Outdated
Show resolved
Hide resolved
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
| // See LICENSE in the project root for license information. | ||
|
|
||
| import * as path from 'node:path'; | ||
| import { FileSystem } from '@rushstack/node-core-library'; |
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.
How much more complicated would it be to mock FileSystem in these tests and avoid the disk accesses? Having unit tests modify the file system is very much an antipattern.
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.
lmk what you think of 85c9e58 (#5467)
libraries/rush-lib/src/logic/pnpm/test/PnpmWorkspaceFile.test.ts
Outdated
Show resolved
Hide resolved
| .: | ||
| dependencies: | ||
| react: | ||
| specifier: 'catalog:' |
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.
Since catalog: is just shorthand for catalog:default, should we prefer the latter for clarity?
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 this example lockfile or more generally?
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Signed-off-by: Aramis Sennyey <[email protected]>
Summary
Adds support for defining pnpm catalog values to pnpm-config.json. This makes updating versions across a monorepo way easier because you can specify a version once and it gets picked up in a bunch of other places.
Details
https://pnpm.io/9.x/catalogs, basically this allows using an alias for common versions to reduce the size of changesets that target global versions.
My goal is for this to resemble the existing pnpm options. Weirdly, this needs to be in the pnpm-workspace file and isn't supported as a package.json pnpm property.
How it was tested
Added unit tests.
Tested in our monorepo with a
catalog:package forinstall/updateandadd. Thecatalog:specifier works for all 3, for install, a newcatalogtop level property is added into the lockfile and for add, ifcatalog:is the global version, add will automatically use it for new packages. I also tested that the temp shrinkwrap files still work, they use the resolved version in the specifier.I will likely need a preview version to test this with publish to make sure it works there as well.
Impacted documentation
Not sure? Might need additional documentation where pnpm-options values are described.