@hydranium/langium 1.0.0-next.210 → 1.0.0-next.213

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/README.md +2 -2
  2. package/package.json +2 -2
package/README.md CHANGED
@@ -19,8 +19,8 @@ silently start returning `false`. Without the pin, single-copy is only a semver-
19
19
  one minor bump away from breaking.
20
20
 
21
21
  For an **adopter**, the reason to route imports here is not runtime identity (that already holds) —
22
- it is **version coupling**. Langium sits in an atomic chain with `vscode-languageserver`,
23
- `vscode-languageserver-protocol` and `vscode-jsonrpc`, with no independently movable link. An
22
+ it is **version coupling**. Langium sits in a chain with `vscode-languageserver`,
23
+ `vscode-languageserver-protocol` and `vscode-jsonrpc`, whose links move together. An
24
24
  adopter importing `langium` directly owns that pin itself and can drift out of lockstep with the
25
25
  framework it composes; importing it from here means the framework owns it.
26
26
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@hydranium/langium",
3
- "version": "1.0.0-next.210",
3
+ "version": "1.0.0-next.213",
4
4
  "description": "Augmented re-export of the Langium API for the hydranium framework: the single chokepoint where hydranium pins the Langium version and layers its type/namespace augmentations. ~99% passthrough today.",
5
5
  "keywords": [
6
6
  "hydranium",
@@ -85,6 +85,6 @@
85
85
  "engines": {
86
86
  "node": ">=22.13"
87
87
  },
88
- "//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.",
88
+ "//prepack": "The publish guard, a `prepack` rather than a `prepare`: `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. 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.",
89
89
  "//sideEffects": "NOT `false`, and the two entries are load-bearing. `augmentations/uri-utils.js` mutates the runtime `UriUtils` object it imports from `langium`, and `index.js` is the only module that loads it — everything else there is `export * from 'langium'`. Declared side-effect-free, a bundler rewrites an import of any symbol from this package straight through to `langium` and skips `index.js` entirely, so `UriUtils.toUri` / `.isAncestorOrEqual` are simply absent at runtime. Nothing fails at build time: the augmentation is a type-level `declare module` merge, so the call still typechecks. `./lsp` and `./node` are pure passthroughs of the upstream subpaths and deliberately not listed."
90
90
  }