First, the premise of this item is wrong: 'an over-narrow declaration gets refused by the version gate' does not hold in measurement here.So this page records 'nothing happened' instead of 'refused' — which is the more dangerous outcome.
Three measured stages
| Stage | Expected (community claim) | Measured |
|---|---|---|
| pnpm install | refused | Succeeded, only peer-dependency warnings |
| dump-config composition | listed but not loaded | Composed normally as - id: dsh-context, no refusal recorded |
| Booting web | does not run | Silent hang: seventy seconds of zero output, process alive, no error |
So how wide should you declare
- engines.dsh blocks nothing either way, so its real function is to inform people, not constrain machines. Declaring narrowly at least documents your intent for maintainers.
- What decides loadability is client.inject.If your plugin injects client packages, a host lacking them hangs outright and no engines range saves it.
- Server-only plugins (no client subtree) are far safer — the billion-context control declares only node and starts fine.
One thing you can do as a plugin author
State in your README exactly which inject targets the host must provide. That is far more useful than a range of versions in engines.dsh, because ranges are never validated while missing packages leave people stuck with no clue.
As a user: compute the inject difference before installing. The verification table on /plugins/ does exactly that — four of thirteen plugins hang silently, all from missing inject packages.