the package.json of concat-stream@1.6.2
"engines": [
"node >= 0.8"
],will produce this entry in pnpm-lock.yaml
packages:
/concat-stream/1.6.2:
resolution: ...
engines: {'0': node >= 0.8}actual: {'0': node >= 0.8}
expected: [node >= 0.8](yaml parse demo)
pnpm version:
5581e4e
Code to reproduce the issue:
git clone --depth 1 https://github.com/pnpm/pnpm /tmp/pnpm
cd /tmp/pnpm
grep "node >=" pnpm-lock.yaml
Actual behavior:
engines: {'0': node >= 0.8}
engines: {'0': node >=0.6.0}
engines: {'0': node >= 0.2.0}
engines: {'0': node >=0.6.0}
Expected behavior:
engines: [node >= 0.8]
engines: [node >=0.6.0]
engines: [node >= 0.2.0]
engines: [node >=0.6.0]
and in packages/lockfile-types/lib/index.d.ts
export interface PackageSnapshot {
// ...
resolution: LockfileResolution;
dependencies?: ResolvedDependencies;
// ...
engines?: string[] | {
node?: string;
npm?: string;
};
// ...
}alternative solution
always store engines as object
problem: string parsing
but: we must parse the strings anyway (sooner or later)
engines: {node: >= 0.8}
engines: {node: >=0.6.0}
engines: {node: >= 0.2.0}
engines: {node: >=0.6.0}
related
i noticed this by running validate-lockfile.mjs from #4517
the package.json of concat-stream@1.6.2
will produce this entry in pnpm-lock.yaml
(yaml parse demo)
pnpm version:
5581e4e
Code to reproduce the issue:
Actual behavior:
Expected behavior:
and in
packages/lockfile-types/lib/index.d.tsalternative solution
always store
enginesas objectproblem: string parsing
but: we must parse the strings anyway (sooner or later)
related
i noticed this by running
validate-lockfile.mjsfrom #4517