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
Description
pnpm documentation doesn't even reference the
pnpm.overridesfield in the package.json anymore. All configuration should occur in thepnpm-workspace.yamlfile.At a minimum, syncpack should treat
overridesin 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
overridesfield in thepnpm-workspace.yamlfile 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