// for historical reasons, publishConfig in package.json can contain ANY config
// keys that npm supports in .npmrc files and elsewhere. We *may* want to
// revisit this at some point, and have a minimal set that's a SemVer-major
// change that ought to get a RFC written on it.
But considering the potential breaking changes in the future (I doubt so, though; the comment was there 3 major versions prior), I think it would only be safe to put the explicitly documented fields in the schema.
Aside from the already checked-in access, tag, and registry fields, I only found publishConfig.provenance being mentioned on the npm website, so this PR should suffice for now.
It is mentioned in https://docs.npmjs.com/generating-provenance-statements#using-third-party-package-publishing-tools The description of this field can be found at https://docs.npmjs.com/cli/v10/using-npm/config#provenance
Some additional notes:
Here's a comment from the npm source code:
So technically, all the fields from https://docs.npmjs.com/cli/v10/using-npm/config can be put into the schema of
publishConfig
.But considering the potential breaking changes in the future (I doubt so, though; the comment was there 3 major versions prior), I think it would only be safe to put the explicitly documented fields in the schema. Aside from the already checked-in
access
,tag
, andregistry
fields, I only foundpublishConfig.provenance
being mentioned on the npm website, so this PR should suffice for now.