Feature Description
requirements.md sets out what a consuming project has to satisfy: Node 22.13, one physical copy of Langium and the wire stack beneath it, and a resolver that reads exports. Two of those are not backed by anything in the published manifests.
Langium carries no peer declaration. That document explains that each head declares vscode-jsonrpc at exactly 9.0.1, that @hydranium/core declares vscode-languageserver at ~10.0.1 and vscode-languageserver-protocol at ~3.18.1, and that supplying something else yields a named ERESOLVE line rather than a silent resolution. Langium sits at the head of that same chain and appears in no peerDependencies block. It is named only by @hydranium/langium, as "langium": "4.3.1" under dependencies. A consuming project that declares its own Langium range therefore gets no such line: npm satisfies both, nests a second copy, and identity comparisons begin returning false — the failure the pin exists to prevent. The documented remedy is a root overrides block, a manual step with no diagnostic behind it.
No TypeScript floor is stated. requirements.md requires moduleResolution set to Bundler, Node16 or NodeNext — a TypeScript setting — but names no TypeScript version, and the word does not appear in the document. Every package declares TypeScript as a devDependency, which a consumer never installs.
Additional Context
The shape of the fix is open in both cases.
For Langium, a peerDependencies entry would turn a conflicting range into the same ERESOLVE line the rest of the chain already produces. An exact-version peer is unusual, and npm installs a missing peer automatically, so it is worth settling whether that improves on the documented overrides route or just adds a second declaration to keep in step with it.
For TypeScript, an optional peer range and a stated floor in requirements.md are alternatives rather than a pair. Either way the floor has to be a version the published declaration files actually compile under.
Feature Description
requirements.mdsets out what a consuming project has to satisfy: Node 22.13, one physical copy of Langium and the wire stack beneath it, and a resolver that readsexports. Two of those are not backed by anything in the published manifests.Langium carries no peer declaration. That document explains that each head declares
vscode-jsonrpcat exactly9.0.1, that@hydranium/coredeclaresvscode-languageserverat~10.0.1andvscode-languageserver-protocolat~3.18.1, and that supplying something else yields a namedERESOLVEline rather than a silent resolution. Langium sits at the head of that same chain and appears in nopeerDependenciesblock. It is named only by@hydranium/langium, as"langium": "4.3.1"underdependencies. A consuming project that declares its own Langium range therefore gets no such line: npm satisfies both, nests a second copy, and identity comparisons begin returningfalse— the failure the pin exists to prevent. The documented remedy is a rootoverridesblock, a manual step with no diagnostic behind it.No TypeScript floor is stated.
requirements.mdrequiresmoduleResolutionset toBundler,Node16orNodeNext— a TypeScript setting — but names no TypeScript version, and the word does not appear in the document. Every package declares TypeScript as adevDependency, which a consumer never installs.Additional Context
The shape of the fix is open in both cases.
For Langium, a
peerDependenciesentry would turn a conflicting range into the sameERESOLVEline the rest of the chain already produces. An exact-version peer is unusual, and npm installs a missing peer automatically, so it is worth settling whether that improves on the documentedoverridesroute or just adds a second declaration to keep in step with it.For TypeScript, an optional peer range and a stated floor in
requirements.mdare alternatives rather than a pair. Either way the floor has to be a version the published declaration files actually compile under.