[Proposal] propagate the repo-declared engines field into published @deepseek-ai/* manifests

[ciceroyang]

Refined ask (thanks to @sjh9714's correction): propagate the already-declared Node floor into the published package manifests.

Original premise corrected: the floor EXISTS and is machine-readable — the monorepo root package.json declares it at line 8:

"engines": { "node": "^22.19.0 || >=24.0.0" }

The gap is distribution, not definition: of the 61 published @deepseek-ai/* packages, only node-addon-landlock-run carries an engines field. The constraint is enforced for contributors and invisible to users.

Propagating it gives two concrete wins:

1. Installers emit EBADENGINE at install time — the failure surfaces before any confusing runtime error.
2. Version-checking tools (the three community dsh doctor implementations converging in 💡 Idea: Add 'dsh doctor' CLI command for environment & dependency diagnostics #1719) stop hardcoding thresholds and read the floor from the installed package — they stay correct across bumps for free.

Evidence: npm view @deepseek-ai/dsh@0.1.0-rc.6 engines → (empty); root package.json line 8 declares the range.

[sjh9714]

Strong ask, and I want to correct one premise in it, since the "nothing upstream to arbitrate" line is mine and I was wrong when I wrote it.

It is declared, and not only in AGENTS.md prose. The monorepo root package.json carries the field itself.

// package.json, line 8
"engines": {
  "node": "^22.19.0 || >=24.0.0"
},

https://github.com/deepseek-ai/deepseek-harness/blob/47f9438/package.json#L8-L10

That changes what this issue is asking for, in a way that should make it easier to land. It is not a request to decide a floor. The floor exists, it is machine-readable, and it is already the source of truth for anyone developing in the repo. The request is only that the published manifests carry the value the repo already declares.

The gap is real and worth fixing exactly as you propose. Of the 61 published @deepseek-ai/* packages, the only one with an engines field is node-addon-landlock-run, which says >=20 and is Linux-only. So the constraint is enforced for contributors and invisible to users.

$ npm view @deepseek-ai/dsh@0.1.0-rc.6 engines
(empty)

Two things follow from propagating it. Installers get the EBADENGINE warning at install time, which catches this before any confusing runtime failure. And version-checking tools stop hardcoding a constant, because they can read the floor out of the installed package and stay correct across bumps for free.

One correction to the evidence line while we are here. ^22.19.0 || >=24.0.0 is the whole-repo constraint rather than something needed "for some paths", and it is strictly above the >=22.15 that built-in zstd needs, so zstd is not what sets the floor. Whatever does set it, the declared range already accounts for it.

dsh-win32 fails below ^22.19.0 || >=24.0.0 today. I want to be clear that this was not independent derivation on our part. The value was copied out of that file, so until this thread it was folklore in our implementation too, just folklore that happened to be right.

[moonquake2004]

+1 from moonquake2004/dsh-doctor (one of the three converging implementations from #1719). This propagation is exactly what lets our node check stop carrying a constant: today E3-node hardcodes ^22.19.0 || >=24.0.0 with provenance pointing at the repo file — once the installed @deepseek-ai/dsh carries engines, the check can read the floor from the installed artifact and stay correct across bumps for free. That mirrors how our E6 tripwire already reads installed-harness contracts instead of baking them in (same introspection philosophy), so we'd treat "engines present in the published manifest" as the anchor. The distribution gap you measured (1 of 61 packages carries engines) is the real issue; the value is already declared at root package.json:8.

Two small implementation notes, in case they help land it:

• A shared build-time injection (read root engines at pack time into each package.json) covers all 61 packages in one mechanism, rather than hand-editing manifests that drift on the next bump.
• engines on published packages is advisory in npm (EBADENGINE warning, not an error, unless engine-strict) — so this is a low-risk distribution fix, not a breaking change.