@hydranium/glsp-server 1.0.0-next.19 → 1.0.0-next.23

package/README.md

@@ -49,6 +49,15 @@ dependency is `uuid`. You must already have a composed hydranium shared services
 tree, a grammar, and a GModel factory of your own — there is no framework GModel
 factory.
 
+**This head needs one line in your own root manifest, and the install works
+without it right up until the server starts.** `@eclipse-glsp/*` depends on
+`vscode-jsonrpc@8.2.0` exactly, while the Langium chain under hydranium pins the
+transport at `9.0.1` — the version this package declares as its peer. Two
+physical copies in one process throw `Unknown parameter structure auto` during
+GLSP server init, and no peer declaration can prevent a nested copy. Add an
+`overrides` block collapsing the chain and reinstall from scratch;
+[Requirements](../../docs/adopting/requirements.md) gives the exact block.
+
 ## Exports
 
 | subpath     | holds                                                                                                                                                                   | platform        |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hydranium/glsp-server",
-  "version": "1.0.0-next.19",
+  "version": "1.0.0-next.23",
   "description": "GLSP protocol head for the hydranium framework. Peer of @hydranium/core/lsp and @hydranium/data-server; built on @hydranium/core.",
   "keywords": [
     "hydranium",
@@ -79,9 +79,9 @@
   "devDependencies": {
     "@eclipse-glsp/protocol": "2.7.0",
     "@eclipse-glsp/server": "2.7.0",
-    "@hydranium/core": "1.0.0-next.19",
-    "@hydranium/langium": "1.0.0-next.19",
-    "@hydranium/protocol": "1.0.0-next.19",
+    "@hydranium/core": "1.0.0-next.23",
+    "@hydranium/langium": "1.0.0-next.23",
+    "@hydranium/protocol": "1.0.0-next.23",
     "inversify": "6.2.2",
     "reflect-metadata": "0.2.2",
     "rimraf": "^5.0.0",
@@ -92,12 +92,12 @@
   "peerDependencies": {
     "@eclipse-glsp/protocol": "^2.6.0",
     "@eclipse-glsp/server": "^2.6.0",
-    "@hydranium/core": "1.0.0-next.19",
-    "@hydranium/langium": "1.0.0-next.19",
-    "@hydranium/protocol": "1.0.0-next.19",
+    "@hydranium/core": "1.0.0-next.23",
+    "@hydranium/langium": "1.0.0-next.23",
+    "@hydranium/protocol": "1.0.0-next.23",
     "inversify": "^6.0.0",
     "reflect-metadata": "^0.2.2",
-    "vscode-jsonrpc": "^8.0.0 || ^9.0.0",
+    "vscode-jsonrpc": "9.0.1",
     "vscode-languageserver-types": "^3.17.5"
   },
   "engines": {
@@ -106,6 +106,7 @@
   "publishConfig": {
     "access": "public"
   },
+  "//peerDependencies": "`vscode-jsonrpc` is EXACT rather than a range, because it is one link of an atomic chain with no independently movable link: `vscode-languageserver-protocol` depends on it at exactly 9.0.1, so any other value an adopter supplies is a SECOND physical copy rather than an upgrade. This wire stack breaks on copy identity rather than on structure — `ParameterStructures.auto` is a singleton compared by `===` in connection.js, so a request type built by one copy and sent over a connection owned by the other throws `Unknown parameter structure auto`. A caret or union range was rejected because npm then resolves a `vscode-jsonrpc@8.2.0` tree SILENTLY, with no diagnostic at all, and the failure surfaces only later at server init. Exact does not fail the install either — npm downgrades an unsatisfiable peer to a warning — but it is a NAMED ERESOLVE warning printing the required version beside the found one, and a hard error for anyone installing with `--strict-peer-deps`. **This is the head where it is not enough**: `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship, so a first install of this package ALWAYS lands two copies and the adopter must pin the chain in their own manifest.",
   "//prepack": "The publish guard, and it deliberately is NOT a `prepare`: npm runs a workspace `prepare` BEFORE the root `postinstall` that applies patches/vscode-jsonrpc+9.0.1.patch, so building there fails on a cold clone and npm rolls the entire install back. `prepack` runs only when a tarball is made (`npm pack`, `npm publish`) and never on install, so it cannot break the install it has no business touching. It FAILS rather than rebuilds, because the rebuild is exactly the part that ordering defeats. What it defends against: `files` lists `lib`, `lib` is gitignored, and a `files` entry matching nothing is skipped SILENTLY — so `npm publish` from an unbuilt tree emits a tarball of `src` and nothing else, with no error.",
   "//sideEffects": "The harness bare-imports `reflect-metadata`, which installs a global `Reflect` polyfill the inversify decorators in this package need before any container is built. That effect is invisible from the module's exports, so a bundler that treats the file as pure may reorder or drop the import and every `@injectable` resolution then fails at runtime. The rest of the package constructs no module-level state beyond frozen constants and DI symbols."
 }