JamieMason
feat: support overrides and catalogs in pnpm-workspace.yaml
Description
pnpm documentation doesn't even reference the pnpm.overrides field in the package.json anymore. All configuration should occur in the pnpm-workspace.yaml file.
At a minimum, syncpack should treat overrides in the yaml file as any other override field. Catalogs would be nice-to-have, but syncing them can be problematic because named catalogs can have version conflicts (i.e. one named catalog can define version A and another can define version B for the same dependency).
Suggested Solution
Implement support for the overrides field in the pnpm-workspace.yaml file to have parity with other overrides fields.
Nested overrides would be nice to have, but I'm unsure what support for those would look like. As a first pass, syncpack can simply ignore and/or warn on the presence of > in dependency identifiers.
Optional comments
No response
Code of Conduct
- [x] I agree to follow the Code of Conduct
It's all good, there are a few different feature requests in here:
pnpm documentation doesn't reference the pnpm.overrides field in the package.json anymore. All configuration is in the pnpm-workspace.yaml file.
Thanks, I didn't know this and can update.
I'd like syncpack to treat overrides in the yaml file as any other override field.
By this I think you mean it should read in this config in the same way as it does from package.json files.
Catalogs would be nice-to-have, but syncing them can be problematic because named catalogs can have version conflicts (i.e. one named catalog can define version A and another can define version B for the same dependency).
You're right that some aspects of it could be tricky, there is feat(pnpm): add support for pnpm catalogs to explore some level of support for catalogs.
Nested overrides would be nice to have, but I'm unsure what support for those would look like.
There is feat(version): try to support the query language within pnpm.overrides to track this, I need to find out what the spec is for the query syntax pnpm uses and then try to support it.
As a first pass, syncpack can simply ignore and/or warn on the presence of > in dependency identifiers.
Thanks, that should be the behaviour now, they get marked up as an unsupported specifier type
