package.json is used as a recipe filename outside the JavaScript ecosystem as well (historically Dub for D). Shared keys such as name, version, and dependencies make it impossible to disambiguate ownership from content alone. Heuristics (deny-lists of "foreign" keys, allow-lists of "native" keys) are brittle and lag new fields.
Proposal
Document a small top-level ecosystem claim for package.json, for example:
{
"packageFormat": "npm"
}Semantics (sketch):
- A tool that reads
package.json SHOULD treat packageFormat as authoritative when present.
- If the value does not match that tool's ecosystem, it MUST ignore or refuse the file rather than partially interpreting overlapping keys.
- Absence remains legacy / ecosystem-defined; new guidance SHOULD NOT treat "no claim" as "this is npm by default" when other ecosystems also scan the filename.
- Filename conventions stay primary for greenfield work (
package.json for npm; other ecosystems use their own names). The field exists for contested / shared filenames and multi-ecosystem monorepos.
Field name is negotiable (packageFormat, extension of packageManager beyond Corepack's JS managers, $schema, etc.). Goal is one agreed key, not a Dub-only convention.
Why bring this here
This group already coordinates package.json field meaning across JS package managers (devEngines, field inventories, etc.). A documented claim would also let non-JS tools interoperate safely without reverse-engineering npm-only keys.
Related
Ask
Is this group willing to consider specifying (or recommending) an explicit ecosystem/format claim on package.json so non-JS consumers and JS tooling can agree on one disambiguation key?
package.jsonis used as a recipe filename outside the JavaScript ecosystem as well (historically Dub for D). Shared keys such asname,version, anddependenciesmake it impossible to disambiguate ownership from content alone. Heuristics (deny-lists of "foreign" keys, allow-lists of "native" keys) are brittle and lag new fields.Proposal
Document a small top-level ecosystem claim for
package.json, for example:{ "packageFormat": "npm" }Semantics (sketch):
package.jsonSHOULD treatpackageFormatas authoritative when present.package.jsonfor npm; other ecosystems use their own names). The field exists for contested / shared filenames and multi-ecosystem monorepos.Field name is negotiable (
packageFormat, extension ofpackageManagerbeyond Corepack's JS managers,$schema, etc.). Goal is one agreed key, not a Dub-only convention.Why bring this here
This group already coordinates
package.jsonfield meaning across JS package managers (devEngines, field inventories, etc.). A documented claim would also let non-JS tools interoperate safely without reverse-engineering npm-only keys.Related
Ask
Is this group willing to consider specifying (or recommending) an explicit ecosystem/format claim on
package.jsonso non-JS consumers and JS tooling can agree on one disambiguation key?