Add strictDepBuilds and trustPolicy
#2180
Conversation
🦋 Changeset detectedLatest commit: cfb5d74 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| echo "--- creating pnpm-workspace.yaml with trustPolicyExclude ---" | ||
| cat > pnpm-workspace.yaml << 'WORKSPACE_EOF' | ||
| trustPolicy: off | ||
| strictDepBuilds: false | ||
| WORKSPACE_EOF |
There was a problem hiding this comment.
Less than ideal 🙈
Still not 100% on the why but it solves the issue where pnpm test:template express-rest-api fail with ERR_PNPM_TRUST_DOWNGRADE because it's using some of the pnpm config 🤔
There was a problem hiding this comment.
Does the same error occur when an engineer tries to init the template? If so, that sounds like something we need to fix (possibly by deleting the template)
|
|
||
| `trustPolicy` (added in [pnpm v10.21](https://github.com/pnpm/pnpm/releases/tag/v10.21.0)) can be set to `no-downgrade` to prevent installing package versions where the trust level has decreased compared to previous releases. For example, if a package was previously published by a trusted publisher but now only has provenance or no trust evidence, installation will fail. `trustPolicyExclude` (added in [pnpm v10.22](https://github.com/pnpm/pnpm/releases/tag/v10.22.0)) allows you to bypass this restriction for specific packages or versions. | ||
|
|
||
| This change also introduces two new overload fields in `package.json` that allow projects to customize these lists: |
There was a problem hiding this comment.
Is there slightly more reason to document this ability than theminimumReleaseAgeExcludeOverload do we think?
There was a problem hiding this comment.
- I'm curious if these should be nested under the
skubakey (and/or eventually moved to askuba.config.ts, or if we want them to be generic for interop with e.g.sku. - How confident are we in our default list? This also has me wanting to look at config dependencies again to avoid an additional layer of abstraction/friction on top of what pnpm supports out of the box (i.e. engineers and agents will try to modify
pnpm-workspace.yamlby default and it's best to meet them there).
| - unrs-resolver | ||
| trustPolicy: no-downgrade | ||
| trustPolicyExclude: | ||
| - '[email protected]' |
There was a problem hiding this comment.
Will remove this once I've tackled seek-oss/aws-codedeploy-hooks#159 and subsequently merged seek-oss/aws-codedeploy-hooks#160 which should mean we only depend on pino@10+
| - '@ast-grep/lang-json' | ||
| - '@datadog/native-appsec' | ||
| - '@datadog/native-iast-taint-tracking' | ||
| - '@datadog/native-metrics' | ||
| - '@datadog/pprof' | ||
| - dd-trace | ||
| - esbuild | ||
| - protobufjs | ||
| - unix-dgram | ||
| - unrs-resolver |
There was a problem hiding this comment.
Haven't actually reviewed these but they are already existing 🙈
zbrydon
changed the title
strictDepBuilds and trustPolicy
72636c
left a comment
72636c
left a comment
There was a problem hiding this comment.
Thanks for this, non-blocking feedback!
| trustPolicyExclude: | ||
| - '[email protected]' | ||
| - '[email protected] || 6.3.1' | ||
| - '[email protected]' # https://github.com/nodejs/undici/issues/4666 |
There was a problem hiding this comment.
Would bumping to @types/node@24 resolve this, or is that a problem for our npm package templates?
| echo "--- creating pnpm-workspace.yaml with trustPolicyExclude ---" | ||
| cat > pnpm-workspace.yaml << 'WORKSPACE_EOF' | ||
| trustPolicy: off | ||
| strictDepBuilds: false | ||
| WORKSPACE_EOF |
There was a problem hiding this comment.
Does the same error occur when an engineer tries to init the template? If so, that sounds like something we need to fix (possibly by deleting the template)
|
|
||
| `trustPolicy` (added in [pnpm v10.21](https://github.com/pnpm/pnpm/releases/tag/v10.21.0)) can be set to `no-downgrade` to prevent installing package versions where the trust level has decreased compared to previous releases. For example, if a package was previously published by a trusted publisher but now only has provenance or no trust evidence, installation will fail. `trustPolicyExclude` (added in [pnpm v10.22](https://github.com/pnpm/pnpm/releases/tag/v10.22.0)) allows you to bypass this restriction for specific packages or versions. | ||
|
|
||
| This change also introduces two new overload fields in `package.json` that allow projects to customize these lists: |
There was a problem hiding this comment.
- I'm curious if these should be nested under the
skubakey (and/or eventually moved to askuba.config.ts, or if we want them to be generic for interop with e.g.sku. - How confident are we in our default list? This also has me wanting to look at config dependencies again to avoid an additional layer of abstraction/friction on top of what pnpm supports out of the box (i.e. engineers and agents will try to modify
pnpm-workspace.yamlby default and it's best to meet them there).
#2175