{"_id":"@hydranium/cli","_rev":"105-8e5e9c5fd02402b43350f09860ee314e","name":"@hydranium/cli","dist-tags":{"latest":"1.0.0-next.185"},"versions":{"1.0.0-next.4":{"name":"@hydranium/cli","version":"1.0.0-next.4","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.4","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"b420da5dcffc51b5895f94b5e35d28af14233bda","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.4.tgz","fileCount":267,"integrity":"sha512-QR/ny0OstvXg+lERkoTVg2GaAPJPPsun0y36CRVB2UTXmL6mOQdh6Lg718s9ZsNjB6XQA5yUgsBqtnxCGtr20A==","signatures":[{"sig":"MEUCID0g6R7mZFrApQ4BNyEOiJKa6SL2ccucbfsdG+EQvznAAiEAnKV7loUU83uCMcM4tyMHE1zfH9dYhz8Ksr4ZmsSyOtI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"1a9c19ae00d0cf51baf7e7c7265de5649dbd2201","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"mfleck","email":"mfleck@eclipsesource.com"},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"10.9.2","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.4","@hydranium/langium":"1.0.0-next.4","@hydranium/protocol":"1.0.0-next.4","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.4"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.4","@hydranium/langium":"1.0.0-next.4","@hydranium/protocol":"1.0.0-next.4","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.4"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.4_1788908648877_0.645960652198946","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.5":{"name":"@hydranium/cli","version":"1.0.0-next.5","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.5","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"b8adb63a06489cd3150f35eb6833adec8aa68688","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.5.tgz","fileCount":267,"integrity":"sha512-5Zmm2WtzS8BHlnLVB7pXoZF6mhKytoC1kdvtLmySWfCC7oPFxuTsAunS7/mdqQneM85zBDI88p4hiZUkALOxKg==","signatures":[{"sig":"MEYCIQCRqYentxwDG0i4iOrbpPqzcZo5WQW+vKmzmHcgMWOfswIhAIoUNXLrH+3mqfzIVSUjakWYZGQcK+tRBdHHJHyjbbLs","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.5","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f5015cdb0f6c921eacbda8fb315f82ffcb02d809","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.5","@hydranium/langium":"1.0.0-next.5","@hydranium/protocol":"1.0.0-next.5","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.5"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.5","@hydranium/langium":"1.0.0-next.5","@hydranium/protocol":"1.0.0-next.5","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.5"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.5_1788911120496_0.07054347161470731","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.6":{"name":"@hydranium/cli","version":"1.0.0-next.6","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.6","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6626934bb7ff03f0bb1545cb939bb112c85176c5","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.6.tgz","fileCount":267,"integrity":"sha512-8va14q0DqlAEcYWQJt9OZ2f8xnVy8o2xj2KHrkfBmutCJ6G1gGrrVrYvpz1ppEr9AouaaO4+3ilzg8dxQmfb/g==","signatures":[{"sig":"MEYCIQCJJqHb9ASzHqWF9VHoX2dK/Tdhu32iPBYj+oNn3HZePwIhAM/HTj+VhYnZKDd+P/poUP+FdvoKSGkaVDQvDscd5JUF","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.6","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"ff6cf31235dd051e35a6fed0799cac3b71a26192","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.6","@hydranium/langium":"1.0.0-next.6","@hydranium/protocol":"1.0.0-next.6","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.6"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.6","@hydranium/langium":"1.0.0-next.6","@hydranium/protocol":"1.0.0-next.6","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.6"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.6_1788945360174_0.49882098642897166","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.7":{"name":"@hydranium/cli","version":"1.0.0-next.7","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.7","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"b596735736e7874dada8705b70ee4d8bd02cf61e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.7.tgz","fileCount":267,"integrity":"sha512-CT7LPqS+EXw9Fd7d8/ip7tqZ4PS8Swf/iOGj8+ZXBYYHMqRzLLffOL+fneQhvcDQN3CVvhzRof2H3AmQCZSpsQ==","signatures":[{"sig":"MEUCIBu152nJdme5Mun1B4N7h+soa1gfyA/QQ5O6RJze+tXYAiEAwlBJKWRL7+q0CvgCah6cj69G93kn/K9l7hB7kwUDRnQ=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.7","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"d03f6f4fc7bb5b114df9eb43fe8a4fd260fa225e","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.7","@hydranium/langium":"1.0.0-next.7","@hydranium/protocol":"1.0.0-next.7","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.7"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.7","@hydranium/langium":"1.0.0-next.7","@hydranium/protocol":"1.0.0-next.7","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.7"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.7_1788953493783_0.17821537857348302","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.8":{"name":"@hydranium/cli","version":"1.0.0-next.8","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.8","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a80487d1835086aa3b5d8ee50277bcb794c9efcb","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.8.tgz","fileCount":267,"integrity":"sha512-iS8tP3Ki3YWHv44cCV7xhLbe2/EX44P25p528KdzfJHXgvsOJ3m5eeqGXZwI4+hfSToq317IaVHsFqG+icGkmQ==","signatures":[{"sig":"MEYCIQCX1uJXwJdUAZeJOnRVeqjxGzl4j89CJlYvNCdRngEJEAIhAKTeUrTEvIc83AAAh+vt3ZH88uXV06OYWtsaaiyvgnWi","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.8","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"9a14d2811974e7d8c0be2ae7694173eabe4c53cc","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.8","@hydranium/langium":"1.0.0-next.8","@hydranium/protocol":"1.0.0-next.8","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.8"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.8","@hydranium/langium":"1.0.0-next.8","@hydranium/protocol":"1.0.0-next.8","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.8"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.8_1788953982354_0.8701193768316553","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.9":{"name":"@hydranium/cli","version":"1.0.0-next.9","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.9","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"0a7f906c90a563dad8fa6d39f9a46038cad99a3c","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.9.tgz","fileCount":267,"integrity":"sha512-rCQ6qkAh0liHEAP01/ctAEVHaGB/93EF+0DzD6TyroMnqkHmlHnKwXi2sb3qzaoSbfvIcoJ+UmfJhlsgUObO1Q==","signatures":[{"sig":"MEYCIQCdCIB2d8VB3IiS6EMXHAyk6Pmlx61eyi/IXQqxYO3u7gIhAPL3QTs1PrCxq3vqibibiMVuitCsDcYPnHE7L0aTS1w7","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.9","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174898},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5c4804b9a2b192c743997952bcd0c53efd740816","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.9","@hydranium/langium":"1.0.0-next.9","@hydranium/protocol":"1.0.0-next.9","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.9"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.9","@hydranium/langium":"1.0.0-next.9","@hydranium/protocol":"1.0.0-next.9","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.9"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.9_1788958068401_0.9352711220592811","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.10":{"name":"@hydranium/cli","version":"1.0.0-next.10","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.10","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"ef8bb5deb1c5fcf54ffb2e8f875169d952373de1","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.10.tgz","fileCount":267,"integrity":"sha512-nV7lUE9CFZUkBKhfMGoxWGbg8BMrNVMwN3aQyjyDW+YBJjaA7gqulNMcQ1FyKXm8p/44ALHdfKZHU7eNh+LHVQ==","signatures":[{"sig":"MEUCIB0A8rb31ahmDnrM5x++10LNj4W4xNKUTdmFFavJgScyAiEAzVdEUmUG0lDuW2QiUgaRiqN9RCOMqdbON0QS52EmO1I=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.10","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"df66e1a949244721ac48fd2ea072f7f2c89cf013","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.10","@hydranium/langium":"1.0.0-next.10","@hydranium/protocol":"1.0.0-next.10","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.10"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.10","@hydranium/langium":"1.0.0-next.10","@hydranium/protocol":"1.0.0-next.10","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.10"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.10_1788962800635_0.06468913376174479","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.11":{"name":"@hydranium/cli","version":"1.0.0-next.11","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.11","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"df3e3f12b10c9049e49b91b18ffd68f762b77933","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.11.tgz","fileCount":267,"integrity":"sha512-vtZEeje0cea910w26hVCC7pX4Ao0p9eCdQSQylcvZSLU7gtmlc2W1uhXToGWGEaR4Vhtjemm7MfvGVqFo5Mf5w==","signatures":[{"sig":"MEUCIQCeZy2ipCMAziFuSOpaGxqtzi90+Y1Pb2Wss9wc74PcuAIgTMes3c3s/WzcUeAj1UU/voMpehb6O9D0BNTBNQz4Z+M=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.11","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"a4732457347fc331a6f3bee38f8cb43051df499f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.11","@hydranium/langium":"1.0.0-next.11","@hydranium/protocol":"1.0.0-next.11","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.11"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.11","@hydranium/langium":"1.0.0-next.11","@hydranium/protocol":"1.0.0-next.11","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.11"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.11_1788963466773_0.8233220667366461","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.12":{"name":"@hydranium/cli","version":"1.0.0-next.12","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.12","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"d2327821102b89e3b339102029bdceb123c9d7a7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.12.tgz","fileCount":267,"integrity":"sha512-fqsv1Vn2KaNJw/FurWf/8068hWmob/ZJt3THkmtS3guZeELRzvHG4Hz43CMSJ6k/ONWKPRdarbx7rR2fmU46dA==","signatures":[{"sig":"MEUCIQCikAVfHHMWA5bStYRF4G6vCYJKrRitmkBI9l7TQxZr1AIgBSVZYZ7Erv8/xPF6bzbTkyG62T19mw2pPy4/bF72+bw=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.12","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"ab9568ab15443597620edc79187d92f0ea68354f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.12","@hydranium/langium":"1.0.0-next.12","@hydranium/protocol":"1.0.0-next.12","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.12"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.12","@hydranium/langium":"1.0.0-next.12","@hydranium/protocol":"1.0.0-next.12","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.12"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.12_1788969540526_0.6573649986715038","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.13":{"name":"@hydranium/cli","version":"1.0.0-next.13","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.13","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"423ac3fd067763bfa8133383cde68fdf10b87dbd","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.13.tgz","fileCount":267,"integrity":"sha512-PvmNn1w38CO94/KmCZ5P1MOAMjGlbuSuyjhnKusJ30WrJ2tk9AlyTJR989WrqaLuLKqpQnIoiutRsmawfQBeKw==","signatures":[{"sig":"MEQCIElEGrXyBhDv0B0F1M6jexEGXXB7VqFf0rqXQJf0RcvnAiAzUz65nmiwTV7rJWt1jcwUG6D7x3uXj9jn1l7puoVfGg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.13","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"7f5d29a1ace1f03b0a3f0f7278182beb408048bb","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.13","@hydranium/langium":"1.0.0-next.13","@hydranium/protocol":"1.0.0-next.13","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.13"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.13","@hydranium/langium":"1.0.0-next.13","@hydranium/protocol":"1.0.0-next.13","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.13"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.13_1789027761351_0.363036918359966","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.14":{"name":"@hydranium/cli","version":"1.0.0-next.14","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.14","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6b0cac6167d3951412f1caf8a98fea24984fc0e7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.14.tgz","fileCount":267,"integrity":"sha512-WDFCa6p3d5TEphmw+WPa+euoQNQgvaSIhWPS5CjfaS/DevNzO0/JPltbaH9c+lvl40H3KZHpZJAWAosW3fpHVg==","signatures":[{"sig":"MEQCIGxNq6IteMX9K7/N552IxIvTmYdAsisyJ8NEsqTs1GtNAiAayiOB3Ml1934mBKHqdC9LoMwIWS3kx+P+RMNj41G2BA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.14","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"ceb4d6188cc57a327ade5469af6a220bc5b5bf0c","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.14","@hydranium/langium":"1.0.0-next.14","@hydranium/protocol":"1.0.0-next.14","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.14"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.14","@hydranium/langium":"1.0.0-next.14","@hydranium/protocol":"1.0.0-next.14","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.14"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.14_1789032167607_0.37332398213543216","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.15":{"name":"@hydranium/cli","version":"1.0.0-next.15","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.15","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"c513909564c431dfa5bc0183bf54de27f6d9f3ef","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.15.tgz","fileCount":267,"integrity":"sha512-DUkvkWwjBVl4fGX/GFeQqfimSrFpoLPXjfmgqnMnoYl5FjoUnFE2zefoYiKsvobaUdO9LOg8WfV06v1/bi5+PQ==","signatures":[{"sig":"MEUCIQCToJETL85U0eSB/Gj8KtudzvY1O79JG6KXUbTEBhuH9AIgaRX3Jsr/LVnMQ2eDh2rqtfLWQpR4cTLrdFxbG5G8fRc=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.15","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"65f465437d22972c3a50c6be1419e791a59140ac","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.15","@hydranium/langium":"1.0.0-next.15","@hydranium/protocol":"1.0.0-next.15","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.15"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.15","@hydranium/langium":"1.0.0-next.15","@hydranium/protocol":"1.0.0-next.15","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.15"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.15_1789032709779_0.9949829206699392","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.16":{"name":"@hydranium/cli","version":"1.0.0-next.16","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.16","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"ffc82ffc065ceef3540b0ac7cb400d99e104f81e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.16.tgz","fileCount":267,"integrity":"sha512-+Ur+aVm0TFNsiypmmjUHhsuNVJwgXkYID7alq/k/COAVJd3i9TfHTMXtsI3gayF580B0iVH2BojCAwDnMyoyhA==","signatures":[{"sig":"MEYCIQCYa+VEw9/reCgSRW1vtRDaf5X5wwZUB7105J4LXvVmCwIhAIkkxgoMbLXNXuZkzfwYyqZB4Mo1hcD9Vb/SSroF1yQZ","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.16","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"c1f791ba46d6e8c824a20b3f04a1ea065d97293d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.16","@hydranium/langium":"1.0.0-next.16","@hydranium/protocol":"1.0.0-next.16","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.16"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.16","@hydranium/langium":"1.0.0-next.16","@hydranium/protocol":"1.0.0-next.16","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.16"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.16_1789033796361_0.9127059960939534","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.17":{"name":"@hydranium/cli","version":"1.0.0-next.17","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.17","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"c44ea91150267fa0f7830016990307cf3f151367","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.17.tgz","fileCount":267,"integrity":"sha512-6mZ3j94PdvFZw/wJE7qIor0alrSUUQp3KT7z4lOCpI5u1Wyp2p+egKocha2EoxGGZfdEe+ZWd8HcjOvrnXVeHw==","signatures":[{"sig":"MEUCIA+uSmwlaP2W4HdC0xz7uceJup3hB0SbM65loAagiblTAiEAhe05E4bocI5yzPbk/VY5qjfRuWnt4PQeoKywkcmGEjU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.17","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"6d4d2f2deccdbbc13eb11ff633a3887e6d977a72","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.17","@hydranium/langium":"1.0.0-next.17","@hydranium/protocol":"1.0.0-next.17","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.17"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.17","@hydranium/langium":"1.0.0-next.17","@hydranium/protocol":"1.0.0-next.17","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.17"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.17_1789037129391_0.6537354107158797","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.18":{"name":"@hydranium/cli","version":"1.0.0-next.18","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.18","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"fa5d5cbed506c9eea15eee0a989088c2a4842a40","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.18.tgz","fileCount":267,"integrity":"sha512-lYnjJ5rKEGzCjC9YNVD1Apm6n67lVcovwiHGEauBRUbC+X/+qoQJsvdX+uHS5ynFAGuUzuBWqDEt9kccdLj1cQ==","signatures":[{"sig":"MEYCIQC0x9i7ZGbBEySrZT6bidIrZ7NdfkfGSHYP6gkhTrdWFwIhAO4WMDAXFv8uy7fLYu0OZWAV/foVVS5pCbs01MWaeJ3H","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.18","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"45f73468e05c55b570b298470deeac748abcdb4d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.18","@hydranium/langium":"1.0.0-next.18","@hydranium/protocol":"1.0.0-next.18","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.18"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.18","@hydranium/langium":"1.0.0-next.18","@hydranium/protocol":"1.0.0-next.18","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.18"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.18_1789038232854_0.9509182867675592","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.19":{"name":"@hydranium/cli","version":"1.0.0-next.19","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.19","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6af7cb3f523c174c9c46c1f09a5e40c1d0959937","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.19.tgz","fileCount":267,"integrity":"sha512-E7Sq6mF0aLhoSujm5O+GDgim+vMa1b29kJKSv7fe9GQBjFjgUak5iMyGasnA6h3sw2e56UNE25ZJgWxJN0EMbg==","signatures":[{"sig":"MEUCIGx9G1JWbLFSngl6w5ySicKohKl0XtI/Q6RdtX9dZiE/AiEAgPv2YNgd4LOzFDWpdEkCkE68N9G5AIGRziJh3BPEVko=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.19","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1174907},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"cfb68570ae14c4b434bd31a4c5f8f59d007c92c6","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.19","@hydranium/langium":"1.0.0-next.19","@hydranium/protocol":"1.0.0-next.19","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.19"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"^8.0.0 || ^9.0.0","@hydranium/core":"1.0.0-next.19","@hydranium/langium":"1.0.0-next.19","@hydranium/protocol":"1.0.0-next.19","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.19"},"peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.19_1789046937185_0.39068046105538223","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.22":{"name":"@hydranium/cli","version":"1.0.0-next.22","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.22","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"3a2175f5ef57c27d5698823d6f44b07462e9e9b6","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.22.tgz","fileCount":267,"integrity":"sha512-U6ISCaoFRX9KDyAarX4nSce4aqML7n1wV36e+Hv3LQrFlEkDfOjUoj9h1mC5XbjPTbo93/vH6qrccNa4UFcyVg==","signatures":[{"sig":"MEUCIQCElUCqX4LxAX9jXvKEf6OSxylmPkAKefTP3qoM3H8aMQIgQCzqdCmkWojQZc8FvlMdkqaF3CFtRoDtk6Ryc+FoS8s=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.22","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1176125},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"4760e9872df915a5ff865eefe8d7d755bd652edd","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.22","@hydranium/langium":"1.0.0-next.22","@hydranium/protocol":"1.0.0-next.22","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.22"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.22","@hydranium/langium":"1.0.0-next.22","@hydranium/protocol":"1.0.0-next.22","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.22"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.22_1789071940707_0.13650038086639116","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.23":{"name":"@hydranium/cli","version":"1.0.0-next.23","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.23","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"29349496bf77c02659411146d950d6dee77fd189","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.23.tgz","fileCount":267,"integrity":"sha512-ZRH5VB9nXiARXmvzab39QpTvbiUmxlhQeg2NVT4yGBgazYBWyq5IqAeSMYbVFLnWwvnLKreyD/Hby/ia4I9C6A==","signatures":[{"sig":"MEQCIBsS7BLRx7yrPYBfGyZDqyGYmYP0bBVCafolbmY2PjVnAiACvLrdup8whF92XbtG2vfdUyPhldDy0VAeaMNJqxPqcg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.23","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1176125},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"68adb62594d9eb65eb8b75d0ebe326a48f75b56f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.23","@hydranium/langium":"1.0.0-next.23","@hydranium/protocol":"1.0.0-next.23","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.23"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.23","@hydranium/langium":"1.0.0-next.23","@hydranium/protocol":"1.0.0-next.23","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.23"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.23_1789073157650_0.7733297816936409","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.24":{"name":"@hydranium/cli","version":"1.0.0-next.24","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.24","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"61ea1f514287d7d6144aa4a8aa22d257267c4c7d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.24.tgz","fileCount":267,"integrity":"sha512-OUtfuutVcug+8snoDN+ft2RD7kyO0nV7qbjgaJmy4zhx/IshGtrt+VrJfvPDFfFeJU/m2nPAWvnvtTK+qNgyeQ==","signatures":[{"sig":"MEQCIFaOwbGSi5mNNmbleZc1WRfryik2EGeYI6IimTwD1V7oAiBATTT3XWFkYzYM5xpLgW6aVDU6QwviSywmZPrh8gJkFQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.24","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1176125},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f15d0358de98a5c446955533021308196bf98b9b","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.24","@hydranium/langium":"1.0.0-next.24","@hydranium/protocol":"1.0.0-next.24","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.24"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.24","@hydranium/langium":"1.0.0-next.24","@hydranium/protocol":"1.0.0-next.24","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.24"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.24_1789074015005_0.45800699805899026","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.25":{"name":"@hydranium/cli","version":"1.0.0-next.25","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.25","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"ba6fe924dd11502ecec642f60b8d7162e3c457cf","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.25.tgz","fileCount":267,"integrity":"sha512-Hn6zrGKyJz3/WLFKSU1+LflJoSm6EtIlZcHeFwEevBbx962aAMAJS8pNIFXkm2bHlfgADtkz07fxUZNCNNHAsQ==","signatures":[{"sig":"MEQCIF8kfCm8IEX3VgTyImc90oYVxn7hPSsrSpanPVJYrECCAiAXXZyk3unQK4LlQHEyVWtx6UHky5/j/wywHFqsqBst5Q==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.25","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1176125},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"b69d464b0c1b93346cd29f9ca4f1cf8f1e8cf289","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.25","@hydranium/langium":"1.0.0-next.25","@hydranium/protocol":"1.0.0-next.25","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.25"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.25","@hydranium/langium":"1.0.0-next.25","@hydranium/protocol":"1.0.0-next.25","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.25"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.25_1789075091080_0.1343739615752475","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.27":{"name":"@hydranium/cli","version":"1.0.0-next.27","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.27","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4427b5f1af8c747c37c59ac19f2c8297e6331320","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.27.tgz","fileCount":267,"integrity":"sha512-i2AXWVi+9WE0++fEPonASbHlErDTKwGgwZC1Dq+55cJXv6KTySZvsGJFtOADRneW8n5VlgUPtOl+bF/eJTdwLg==","signatures":[{"sig":"MEUCIGAfR0gPnHVH2U0NOSS+NJwhPjIrFRLRQVYuJYRxNqsTAiEAuP8Tsc3/dIpCp4YaJkKwBx0DRkQfaRFAE7JnbLrVD+w=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.27","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1176125},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f0ad5bdc8d848ff48a6c0fe2afa6f8400cd96f9f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.27","@hydranium/langium":"1.0.0-next.27","@hydranium/protocol":"1.0.0-next.27","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.27"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.27","@hydranium/langium":"1.0.0-next.27","@hydranium/protocol":"1.0.0-next.27","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.27"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.27_1789076376875_0.29578344539430845","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.28":{"name":"@hydranium/cli","version":"1.0.0-next.28","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.28","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a055494dc9696bcc54d191d9f131bd30428c2f88","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.28.tgz","fileCount":267,"integrity":"sha512-ab4f9pcrNPRo3Cshj/+XnFzTNpVDyxTGkMue+yR3LAoKNH7J75jYdP00XnbsCfOME3MBZv3i4GvUz9ciSz5TCw==","signatures":[{"sig":"MEUCIQCGGKIZVmI8+Pm3sg1/s4iWU2fplHo4TTjr2cO2AbEVTQIgMwbymYmfrJO56c1cm6vsPKgwGH0mKNut5k4bJE8ZL7M=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.28","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1178363},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"206aa8844f1a6c34fb2b2439948828b35c8619df","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.28","@hydranium/langium":"1.0.0-next.28","@hydranium/protocol":"1.0.0-next.28","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.28"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.28","@hydranium/langium":"1.0.0-next.28","@hydranium/protocol":"1.0.0-next.28","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.28"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.28_1789077266125_0.23182374714513987","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.29":{"name":"@hydranium/cli","version":"1.0.0-next.29","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.29","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"12fc6f26b871260f8e2fc86a0afd0eba5b612810","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.29.tgz","fileCount":267,"integrity":"sha512-ZrT3/rH5X7nr4bMiEtZ7q/6jFOjCZlNsONu3e8VnImhXswGq4XyUXAX/qLleT9MuAPIVSS0kkH0cpIavp+PXPg==","signatures":[{"sig":"MEQCIAmze8K+th62MbYuxKuGE+n5Ko9oQvWEwN7Vjr0bl080AiAvPHuKMcM67ljC8eD3fdrhD37tDjdKoU8crkGPDsN2sg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.29","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1178363},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5d176ee3a002deede9bb8a02e179afb865fb8f41","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.29","@hydranium/langium":"1.0.0-next.29","@hydranium/protocol":"1.0.0-next.29","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.29"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.29","@hydranium/langium":"1.0.0-next.29","@hydranium/protocol":"1.0.0-next.29","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.29"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.29_1789079885753_0.5431057773704455","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.30":{"name":"@hydranium/cli","version":"1.0.0-next.30","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.30","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4972e42573c32533803e2974d61ac9d723a391d5","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.30.tgz","fileCount":267,"integrity":"sha512-Yv1Npn7zmfoI8wfkif5Jiw9V5WyJ/yBAH9pZ6qFgGFRHVmkscFSSGnDH0B6cUgm0FABx01D7ijNGcgCMYB3wyg==","signatures":[{"sig":"MEUCIFMOp0MZwwjrb0lA1l4jR3a7hiCoczRiqG1+ZLQe+ZAtAiEAnSw4LkSFaV8hmi4D8q34T66BqIFuNLFEmz/2rTIobdo=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.30","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1178363},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"3144b5a64521d2f949edd8796430813749fe4b55","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.30","@hydranium/langium":"1.0.0-next.30","@hydranium/protocol":"1.0.0-next.30","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.30"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.30","@hydranium/langium":"1.0.0-next.30","@hydranium/protocol":"1.0.0-next.30","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.30"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.30_1789080763352_0.08437338597245314","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.31":{"name":"@hydranium/cli","version":"1.0.0-next.31","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.31","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"aab272a53805360b8d2dafb61180a15aa26c8efa","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.31.tgz","fileCount":272,"integrity":"sha512-pOSUU/Sh8SKMj1u5RpJf2Ktwa57MVTNxozxvs3j03NaA4vOXOKikXOLwGi7UqPecdci8Bk56ltPhbfBtb1gbZA==","signatures":[{"sig":"MEUCIQDjx+MMvui9YOpFvdDFFNbzy6nq5UvyhkBvK9hwfcnYBgIgVBJ+PsocMOEpPElZxxMG/TipByEiJemYSwa2zxfFAu4=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.31","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211739},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"8e6c8c3616f7704c9fa715844ec72402a12fbe5d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.31","@hydranium/langium":"1.0.0-next.31","@hydranium/protocol":"1.0.0-next.31","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.31"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.31","@hydranium/langium":"1.0.0-next.31","@hydranium/protocol":"1.0.0-next.31","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.31"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.31_1789081746804_0.6553556909452616","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.32":{"name":"@hydranium/cli","version":"1.0.0-next.32","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.32","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"41c23631fe611346d6539990b65a4af2b717e761","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.32.tgz","fileCount":272,"integrity":"sha512-smZ66Wy5GB6kqMIxaAP8fuRCUfdnHDG3bmMPQpftI8pLpDWLbLnY09DaiTkK3Ljq5V7qHPdo4ysiHiiNkkwu6Q==","signatures":[{"sig":"MEUCICy2PJijWhNlY/Jafk8r2UWGuu2Tb0tr3/WX13rQ5TxJAiEAlMnTkOKksv1qI8XwgIOVH6pzAXByOjVjabA9dDrm1DM=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.32","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"700db3a0b4b65b843ec58b627d3c97f466fd9177","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.32","@hydranium/langium":"1.0.0-next.32","@hydranium/protocol":"1.0.0-next.32","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.32"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.32","@hydranium/langium":"1.0.0-next.32","@hydranium/protocol":"1.0.0-next.32","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.32"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.32_1789082705110_0.7905587259199631","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.33":{"name":"@hydranium/cli","version":"1.0.0-next.33","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.33","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"78ac81f0f0dd0ba8ce641f81b9313ecb8503d096","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.33.tgz","fileCount":272,"integrity":"sha512-JYbKV1b0Iok+jswCcjmB4Pa1+ExNsHwbYe7rG7MjpMjT6DKRQeaEo4ICLhpE0Jr+mqtJbtCA8T+fbk7SsrAT3Q==","signatures":[{"sig":"MEYCIQCLNJGZvw3jIYFayqXXO8p+u3YVw8t9O9PtCPe86jQmKwIhAKxkhuC9OrZjanr4U4fhA///A+Z8ue455wZAg2zyc2mf","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.33","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bf49242998f9f506ce89544d21740841e1f85d02","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.33","@hydranium/langium":"1.0.0-next.33","@hydranium/protocol":"1.0.0-next.33","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.33"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.33","@hydranium/langium":"1.0.0-next.33","@hydranium/protocol":"1.0.0-next.33","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.33"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.33_1789084255979_0.752172377266396","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.34":{"name":"@hydranium/cli","version":"1.0.0-next.34","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.34","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a07d600beeee4f4a0cdf00fd3b8ea5b386a8083e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.34.tgz","fileCount":272,"integrity":"sha512-DsUMgDDk1NkDT7SajZ0OGevBaQ94rNZaYqNHmSjezhpmVv8wVI7uS9LxzLmGravhHaUlDxLpXYomsthk+Ruzcg==","signatures":[{"sig":"MEUCIC4bPC+08oKA7qZOyOMwI+4yTLp90yzqjZ55S3Jbs6TkAiEAqQYBCjvZ5/mKQDb1cYxoAbXx+7+hIfENYdlT2GCQHJ8=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.34","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"ef11fbc473c423b233f3b84b1fd895c707d435e5","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.34","@hydranium/langium":"1.0.0-next.34","@hydranium/protocol":"1.0.0-next.34","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.34"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.34","@hydranium/langium":"1.0.0-next.34","@hydranium/protocol":"1.0.0-next.34","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.34"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.34_1789084685805_0.37011028811716473","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.35":{"name":"@hydranium/cli","version":"1.0.0-next.35","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.35","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"8cb047e4516c149e1ead6755fc4eee23f969aa96","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.35.tgz","fileCount":272,"integrity":"sha512-ojylU3yuZthgAJKnedAzS+BDCBn9LRqa7kUGMb0Tv7J4xvszgWj7yV2zRAwOZSDjg6YbBDVZprwk+iqMqz4voA==","signatures":[{"sig":"MEYCIQCie9r/h1oG5IUoIUzel5rHsgDlX8sLWpJVQ98ek8MrBwIhAIRnZzxjevC3Y3h+ie/fSEmIPUCb51xawBW7Z4Zfhf3m","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.35","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"a593818fcf7c415740029d85a40c5fddc0d6d252","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.35","@hydranium/langium":"1.0.0-next.35","@hydranium/protocol":"1.0.0-next.35","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.35"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.35","@hydranium/langium":"1.0.0-next.35","@hydranium/protocol":"1.0.0-next.35","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.35"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.35_1789110769207_0.6815054487213483","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.36":{"name":"@hydranium/cli","version":"1.0.0-next.36","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.36","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"8c1fe013c45d60fe99e9b734092bc7071561b327","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.36.tgz","fileCount":272,"integrity":"sha512-qvDA3aaeQm/V9nvviB0ONdJ3h2CnXiy8HOIWrcfpZwzEDAR53wCRZt4jMet5/bWLb8reQGvdE9eOIonEyGeW+w==","signatures":[{"sig":"MEYCIQCvt2ftf6dywteB34RkI9jq6GW10fr8+DPpxoJo2ClVBgIhAI96eWc9q2VbpZ6QUjX5bpg7I2wTwmEF+W/xhoa0bkeS","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.36","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"ecd8fd559bb737ef531c1ebb908b4a00012e6480","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.36","@hydranium/langium":"1.0.0-next.36","@hydranium/protocol":"1.0.0-next.36","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.36"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.36","@hydranium/langium":"1.0.0-next.36","@hydranium/protocol":"1.0.0-next.36","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.36"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.36_1789111465108_0.7794057803423189","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.37":{"name":"@hydranium/cli","version":"1.0.0-next.37","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.37","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"e7291430700f4f6f79bb693f837f841928010185","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.37.tgz","fileCount":272,"integrity":"sha512-VtA1YZ/b1cRaXyJRhlLc+CXfYBpPnzZBQGaqcW0fiLQ3BX/Mza0sMPOsu4jLQb0xsoNfPRrVwitGPf46LRtsaA==","signatures":[{"sig":"MEYCIQDnBgjRe+5ap0mFv1cSiu65dgG7wclI6vwzfO+a5USzVQIhAJwPyr/fzNRPL9s17CIEHuQZZ8m6LchX3j0K//99lNWp","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.37","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"71281468e9eea70a91d68418d466b2c2f9b95e61","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.37","@hydranium/langium":"1.0.0-next.37","@hydranium/protocol":"1.0.0-next.37","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.37"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.37","@hydranium/langium":"1.0.0-next.37","@hydranium/protocol":"1.0.0-next.37","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.37"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.37_1789111898031_0.8797086187134733","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.38":{"name":"@hydranium/cli","version":"1.0.0-next.38","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.38","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"46608799e68ff34039a61baeef02496aa6a4a4b7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.38.tgz","fileCount":272,"integrity":"sha512-BS4P81sGToqN8MZ/tCB+0jXnZ6okbd1OS4UEsVEGwaH/+shMem0xbUFOUKHgs7vgMbjVDeBmcnhIonUiVG26pw==","signatures":[{"sig":"MEUCIQDO0Q3ISARvFjbN+gKQ4tggt24QhThlQvrtA34YD+NbNQIgJslWA6ZTeS8DAeH/R+KKUT0SuYn7lZ4aigzR6NWGJgI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.38","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1213463},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0b55576ebe72990a6f20c437cb4e0206d0da7265","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.38","@hydranium/langium":"1.0.0-next.38","@hydranium/protocol":"1.0.0-next.38","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.38"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.38","@hydranium/langium":"1.0.0-next.38","@hydranium/protocol":"1.0.0-next.38","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.38"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.38_1789112543222_0.8068390124764093","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.39":{"name":"@hydranium/cli","version":"1.0.0-next.39","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.39","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"d6c6fc7e8564645b517bcde3df9df9f0ab59d01f","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.39.tgz","fileCount":272,"integrity":"sha512-tj6sfc52w27+VeOxKcDFjHiAUb8ki+Jxdxhl6KzR96Si8AkponglB+GesMXusaQvdzcZAAflB8LcJuJNYNgYCw==","signatures":[{"sig":"MEQCID4ZzW4H0q1wwBaKRusYeliHR/MRV04gn2DUYM30hH+xAiA8FOktqb4o5WhZKULa+uH81yRH+tmG2dtjd3bQm/b5Fg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.39","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"85360c20902dea3a7e75a1816cb2b66bccc4a8b8","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.39","@hydranium/langium":"1.0.0-next.39","@hydranium/protocol":"1.0.0-next.39","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.39"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.39","@hydranium/langium":"1.0.0-next.39","@hydranium/protocol":"1.0.0-next.39","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.39"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.39_1789113552784_0.06048717111114987","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.40":{"name":"@hydranium/cli","version":"1.0.0-next.40","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.40","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6311f48b09541c9b74c53245bd2a0fe1cedc6e5a","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.40.tgz","fileCount":272,"integrity":"sha512-l2R+FUb3nn1n7ymsvElCF/88QOPDxLTzLMheg6ymNe2nBR6BTXDKcRIkKlA21eShwp5ufSwMfz1IUT4iZl/qHw==","signatures":[{"sig":"MEQCIGhJgQmHhrLry67wqmPReIZ/G0mLcEzLvtRwZ5EWV4GXAiAZp1E8BOwXrgwCWUZDeItH1gWTJUvKFFVJAhPR8HOrfg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.40","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bc342467f388397ab8033e70fbb8af13451a04a9","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.40","@hydranium/langium":"1.0.0-next.40","@hydranium/protocol":"1.0.0-next.40","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.40"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.40","@hydranium/langium":"1.0.0-next.40","@hydranium/protocol":"1.0.0-next.40","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.40"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.40_1789116550612_0.26717192932836276","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.42":{"name":"@hydranium/cli","version":"1.0.0-next.42","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.42","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"d9e9854431b432ed40557f4810c2324509bc00e3","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.42.tgz","fileCount":272,"integrity":"sha512-HmeQtpIuqQxmQZV+XYOrN1iwzvbf78ie2FQcMxM1TiH8/KvPM6YdgGZ1kbLy1yZ9WoMey7ZnBC7GJqtLPRN3SA==","signatures":[{"sig":"MEQCIANF7ZZxLCbR8Qzn9XF/OSBfm+yMCK2G8Ey/ogewLnDEAiADAp4Hlz3cc+QoJNPIQlyjaI28s61DuAYHlF95/5HU3w==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.42","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"1c0395351d8cf4bca5442cce3721b8fa4d7f5177","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.42","@hydranium/langium":"1.0.0-next.42","@hydranium/protocol":"1.0.0-next.42","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.42"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.42","@hydranium/langium":"1.0.0-next.42","@hydranium/protocol":"1.0.0-next.42","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.42"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.42_1789123411816_0.900632195007641","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.44":{"name":"@hydranium/cli","version":"1.0.0-next.44","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.44","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"d67822fbeed1d8b3edf749acd4007e61e76ebc83","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.44.tgz","fileCount":272,"integrity":"sha512-3BBRGS8eFO3+O8AvZRdA6dGA3fC1tnRse1/jZMIWTbfgD6+vrVW89yPpVkXAdgbScLjiLRixgS22hrFD41KwCg==","signatures":[{"sig":"MEYCIQC56xEVT27/yIbm29MBTZt2UOnuXEn0YiVgB55XgLK6EwIhAJNqcWiXJuItJtnvHyqex7YdfAjEM+LRh45e092Te73X","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.44","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"d422b97846df49ade27fc9f59c971520dde807fc","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.44","@hydranium/langium":"1.0.0-next.44","@hydranium/protocol":"1.0.0-next.44","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.44"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.44","@hydranium/langium":"1.0.0-next.44","@hydranium/protocol":"1.0.0-next.44","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.44"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.44_1789127837963_0.7385368225568707","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.45":{"name":"@hydranium/cli","version":"1.0.0-next.45","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.45","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4aee594e3921545496311d05f6abc0d67e8bc412","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.45.tgz","fileCount":272,"integrity":"sha512-+CWT1wxdYJAK0BrJRoRfZeAtCwm3GgRlV7vuqqIbbYV8sk8FsgcocFXPydV+qekmIaDTyn5FDqxSmwf+62SDJA==","signatures":[{"sig":"MEQCIB2KcOqtg/CuqPCmVuag4bEOvJVIV+v6YGPCvIma8R5WAiAbXMBoHWJgTJ7Tl5XdfygNyO5eU/GDPNxBxrjzLMp6kw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.45","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0c2e2da8f3afba96ba16fc3a98115b3cf5f1e0d5","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.45","@hydranium/langium":"1.0.0-next.45","@hydranium/protocol":"1.0.0-next.45","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.45"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.45","@hydranium/langium":"1.0.0-next.45","@hydranium/protocol":"1.0.0-next.45","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.45"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.45_1789129983440_0.481109978225295","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.46":{"name":"@hydranium/cli","version":"1.0.0-next.46","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.46","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"88109486cac7f1f09f15e97f2b2a10c7034cdc06","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.46.tgz","fileCount":272,"integrity":"sha512-RPf8zCqdkHc1bFJiCEJpLxvDtRJ4jKwBXGO7URbSAmuAbDqaGsvc76e5n1eU2DoGj9XCFifi2T5eHva4qNSKJA==","signatures":[{"sig":"MEQCIHYIMVWwtqpgaN6k5vSg7w95kIAoXVgG+jr23gkHu3AEAiBOjI0cjKU5+jchlZOgQhw+r1fS08GN7dHgmyVoGBgCLw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.46","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"df83b12d3657272e7bd994bfeb01953c9b30a8ec","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.46","@hydranium/langium":"1.0.0-next.46","@hydranium/protocol":"1.0.0-next.46","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.46"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.46","@hydranium/langium":"1.0.0-next.46","@hydranium/protocol":"1.0.0-next.46","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.46"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.46_1789131810083_0.42362957222474695","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.49":{"name":"@hydranium/cli","version":"1.0.0-next.49","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.49","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"d1928afe260e144152bc373e7f6e2136106ee55e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.49.tgz","fileCount":272,"integrity":"sha512-xBo+SMy9vmlcHgwEUT5nmsEHfrYO+/qGUu8ut4cD4xd2opcEZ1xSL1+P6hqIJFdNPJO9vjntAblA7yv15Qv32w==","signatures":[{"sig":"MEUCIQCRVsey7PXRR1leElsykEcXaMgM4KXUEAB/NdsIEykIDgIgKDBRhyna3PPx0qmBjS5CuGMJI9gk4tDCgEBEA37BNJU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.49","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1215276},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"b08c1dab6484db2bbbe43c3e07db79155901e217","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.49","@hydranium/langium":"1.0.0-next.49","@hydranium/protocol":"1.0.0-next.49","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.49"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.49","@hydranium/langium":"1.0.0-next.49","@hydranium/protocol":"1.0.0-next.49","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.49"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.49_1789473370534_0.1476543961121275","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.50":{"name":"@hydranium/cli","version":"1.0.0-next.50","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.50","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"964d8f62bceb6d68549f54f981bded59517a5ba7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.50.tgz","fileCount":272,"integrity":"sha512-3TkcEsfRFCtVzSYFSxN9BS+ri2mJ7RAP71GkeP6flAJRiYqmDBW6oeiOqoEcQabhlStPkLApHDnwx0RGViY7PQ==","signatures":[{"sig":"MEUCIQDN6+KhaL3VFZtRr++jG06mpigHsiAzhAHKQq7A77BCuwIgSlqu1v1nHkpjVklSSKhtdIrxSJ+JyTDjSqpQbmnF/uE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.50","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211152},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"2e9b935ebe05c3bfb550a411f09668c28903c603","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.50","@hydranium/langium":"1.0.0-next.50","@hydranium/protocol":"1.0.0-next.50","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.50"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.50","@hydranium/langium":"1.0.0-next.50","@hydranium/protocol":"1.0.0-next.50","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.50"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.50_1789475639490_0.5733364705241955","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.51":{"name":"@hydranium/cli","version":"1.0.0-next.51","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.51","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"74ac2e9df358b3f611a48520b8a5dec48765f526","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.51.tgz","fileCount":272,"integrity":"sha512-c7JJZ9MHqDNjQrWtPkxxW8OqkgDnHB6DA1qyicmq6tDjlWWgK0n/qjF6q4s/C+JdLXZLIND7kQyouuWbqDi1Fg==","signatures":[{"sig":"MEYCIQCu4q0M9G1k3SQEbrwrmy/144uDuBieeOIxXxollFXjjwIhAOE4Aj/gXpUEvsV5Rp7Pn5Yqa7HC2U0FrK5Vui/Bem96","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.51","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5f38a70ec703c96b9211f2632ef9c64b4d35a0e2","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.51","@hydranium/langium":"1.0.0-next.51","@hydranium/protocol":"1.0.0-next.51","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.51"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.51","@hydranium/langium":"1.0.0-next.51","@hydranium/protocol":"1.0.0-next.51","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.51"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.51_1789476901447_0.6461010425230307","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.52":{"name":"@hydranium/cli","version":"1.0.0-next.52","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.52","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"0de336827d0125fc68f6c2c73b8af1e2eaea5216","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.52.tgz","fileCount":272,"integrity":"sha512-Y9oh/6GFtkGEjQYJZ49m7OimmlnpBW7KXxXbN+TTWflCQYVGcHIAMvremzv3LDoTtVn9uDqDzeDl0+z7vNvkVg==","signatures":[{"sig":"MEUCIFNC6m1MFN9Bl7fRZ5kg4x+1/oR3eIu9maveZhFQKA6NAiEArCrSaFNvtqyhcUUQdEhI9qD/gGAPAuRKAvY0acBEDBs=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.52","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"de17637218123da3f6f1393b3f3303178fabf878","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.52","@hydranium/langium":"1.0.0-next.52","@hydranium/protocol":"1.0.0-next.52","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.52"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.52","@hydranium/langium":"1.0.0-next.52","@hydranium/protocol":"1.0.0-next.52","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.52"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.52_1789484047700_0.5924614075908763","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.55":{"name":"@hydranium/cli","version":"1.0.0-next.55","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.55","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"5349a8f47873e742e99572fd622a12c1cc7ab047","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.55.tgz","fileCount":272,"integrity":"sha512-jlzDk2SAk8qLTnh9gt7Nsv3QVcpj7Lh6DJLTMsdTKftfBCKQbE09xGDvetohNbuc55xzp9hrI/CdDHzYtcj5EQ==","signatures":[{"sig":"MEUCIQDEEOWa9NFDcx5w61o82zIpX5epSFmwnF51/DJKkc2R1wIgP367tR4asK4goAx62KzutTmEjD5a+4UbW6FGNoxmYSQ=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.55","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"52533e6c56b9f7c07bc3e90ed6a9fa00dcc17b65","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.55","@hydranium/langium":"1.0.0-next.55","@hydranium/protocol":"1.0.0-next.55","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.55"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.55","@hydranium/langium":"1.0.0-next.55","@hydranium/protocol":"1.0.0-next.55","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.55"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.55_1789563252633_0.1776536457941711","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.57":{"name":"@hydranium/cli","version":"1.0.0-next.57","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.57","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a8334512d89fc2e3372d86798be3a6a162782e3b","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.57.tgz","fileCount":272,"integrity":"sha512-exW2ibb8C8YgjpIpPHDJoWbg/TY9PYUOgZmpAaagfOMIhHQzL1ygSVCiNya+z1rjnYYU2DnNn29Ag+SAePrquw==","signatures":[{"sig":"MEQCIHmY/15AprgnioshuPQ48fLa3zSzuYgGb/0JKN5/efA2AiB01MPFF2mE6FSy4NPqMlq4Rnj13ThKJY7LzuNHc6/OIw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.57","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"8e614f55b457c6f8a5ba228ac58d24f210126eaf","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.57","@hydranium/langium":"1.0.0-next.57","@hydranium/protocol":"1.0.0-next.57","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.57"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.57","@hydranium/langium":"1.0.0-next.57","@hydranium/protocol":"1.0.0-next.57","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.57"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.57_1789572422343_0.5550254403851378","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.58":{"name":"@hydranium/cli","version":"1.0.0-next.58","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.58","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"16d470c7f480aeda730ef892f5e5eb67e4e38cf0","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.58.tgz","fileCount":272,"integrity":"sha512-Se1lOLp5DGFJxidU0tdMmSV6AgJRZp26OQyOqSzTNo54fzWwCFsIRzGMmm2eQt2zS8T1fP6uUbg8/wVnbf786g==","signatures":[{"sig":"MEQCICvlJaKBM+U5473ib5y+SCuRhGWKEUHC9xWuPJGifvO0AiBCsuQKRfpZLi88yHhNNnPPGuXM77nW9gtpF6CzQ3k/KA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.58","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"e11d975dfe5c1946333588c85f2539b2ba0b8831","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.58","@hydranium/langium":"1.0.0-next.58","@hydranium/protocol":"1.0.0-next.58","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.58"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.58","@hydranium/langium":"1.0.0-next.58","@hydranium/protocol":"1.0.0-next.58","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.58"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.58_1789572904883_0.39326377328999684","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.60":{"name":"@hydranium/cli","version":"1.0.0-next.60","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.60","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"962b580fb12991a8ebc5771091ac226efd018a20","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.60.tgz","fileCount":272,"integrity":"sha512-dnhJYv+EdyT1WrCDF4/J/oSuTmJ/VYwSc27K8doBfZ2Iyeo1wxf0SPjzobTVUMWQHKVenuWnajUBRW9Kq6wBjw==","signatures":[{"sig":"MEUCIGxMzGDtYE92UbE5FwjaNZ9KIlTf6kKPioC+/5qMVg0EAiEA6mpNB0xWpDxC/cFsEpmaoucppXbUghPTE/zTEHn5Ui8=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.60","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0e89e5480ccac85e072121bcc4280e4f21b6e5f6","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.60","@hydranium/langium":"1.0.0-next.60","@hydranium/protocol":"1.0.0-next.60","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.60"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.60","@hydranium/langium":"1.0.0-next.60","@hydranium/protocol":"1.0.0-next.60","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.60"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.60_1789634824531_0.7446089216463341","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.61":{"name":"@hydranium/cli","version":"1.0.0-next.61","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.61","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"3c3703554cd45847dd46ab921a4e1c62d455d270","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.61.tgz","fileCount":272,"integrity":"sha512-/iPfmj58UQ+j7ebjcgnwy9t0iqogSSJypjvZHGkv75q/lmuBIleO2P3cR42X6u8K4qAhnqLCrrr2Nm8VmbBsyA==","signatures":[{"sig":"MEUCIQCU1zdYVm6VvT3g6CUShRLdlnfjddgpPvxW4V+ObLmXpwIgevYU759qHDRYSNe1qh4T02vIaUGlmeK0NHGiE/IOevo=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.61","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f2aa66b54903e3b3e4932430bdc99503f5ce36e6","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.61","@hydranium/langium":"1.0.0-next.61","@hydranium/protocol":"1.0.0-next.61","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.61"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.61","@hydranium/langium":"1.0.0-next.61","@hydranium/protocol":"1.0.0-next.61","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.61"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.61_1789643110851_0.5394051270170437","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.62":{"name":"@hydranium/cli","version":"1.0.0-next.62","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.62","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"0209c136bbf4d2861deece87dfdd54ad2fbc0b1d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.62.tgz","fileCount":272,"integrity":"sha512-vjDrdeVA2ebzZO/S6g0FoVUgOPbPyX7TNt719u7bwf9I27tX3xk465LiKqX5ZD8up4HnM0ockULysn8Nhepi/Q==","signatures":[{"sig":"MEYCIQDaD53BusgGWyc8v9om/FzLpFnhIr5sPMUq9Yknk9oBBAIhAKP/FZmE6hty3tb7IuX8bx4fbq8nprTEOluLpTl3reYh","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.62","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"6246734b049f5d6029ddc57bfda9ad0c234ce11e","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.62","@hydranium/langium":"1.0.0-next.62","@hydranium/protocol":"1.0.0-next.62","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.62"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.62","@hydranium/langium":"1.0.0-next.62","@hydranium/protocol":"1.0.0-next.62","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.62"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.62_1789650763466_0.05262544544483427","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.63":{"name":"@hydranium/cli","version":"1.0.0-next.63","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.63","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"57c6767a752bf7e096ba6a642fe0a55fbac74443","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.63.tgz","fileCount":272,"integrity":"sha512-kA6nqKc/o/WNFpw55D9MwHKd0BOrYOZlGFbkglMHwPMxybXikLDEBj+8krnz5/3+Cb5YdmaYGpWA1wDj635SqA==","signatures":[{"sig":"MEUCIDAd2Uxbtmozev4Ij6VI6wIzeqVLFdWQnRrFZV3QbXKCAiEA/Fqz+fy79lqUzmBZY7j+32zgTsfvvyVjG45rnKXrwWs=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.63","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"b5aabccfde4752da8e1efd4017b822eef531559d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.63","@hydranium/langium":"1.0.0-next.63","@hydranium/protocol":"1.0.0-next.63","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.63"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.63","@hydranium/langium":"1.0.0-next.63","@hydranium/protocol":"1.0.0-next.63","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.63"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.63_1789651217795_0.9567038389828104","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.66":{"name":"@hydranium/cli","version":"1.0.0-next.66","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.66","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"090ddf50eeaf280394577f944ad29ed42aa19b9d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.66.tgz","fileCount":272,"integrity":"sha512-ysj8jUBxIeFs7i0ZPPZml6iVnO8cyZikKQYYxslysU6gm12lKQZtQatLHTrVH+u09pU1Uuq+SClwY0wVRH7dNA==","signatures":[{"sig":"MEUCIB50337vaOBj+5DAJAbAIbQ/lBGs3PDvtUjHbzvOqqI1AiEAjLiNw0uldnJXhsyDhOAy2GgB2MCHcNHz58zbFq3RJM4=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIGdht81R0vbTiES0Uja6Lnwe1Ga52M+XfCXJeqyYAy3BAiBIc0xS6W/uPaWh1w03xwHul/9YvYmafc5+gmRSIYZ3lg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.66","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5f76b281e64b2afe365e29c49d7388f20a626482","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.66","@hydranium/langium":"1.0.0-next.66","@hydranium/protocol":"1.0.0-next.66","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.66"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.66","@hydranium/langium":"1.0.0-next.66","@hydranium/protocol":"1.0.0-next.66","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.66"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.66_1789680457367_0.599375479647102","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.67":{"name":"@hydranium/cli","version":"1.0.0-next.67","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.67","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"1711960512e589cc216307fd6b8e5adec11741c7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.67.tgz","fileCount":272,"integrity":"sha512-enILnDl/lfI58E8ihPwf3OvykBsm5jv7f+mSwRgiJa5F3VUIbBgcQFkzNWm8RLvsHEimY7EfmeLThcGN6hHoJg==","signatures":[{"sig":"MEUCID7gNgQy5g7F+JvcOrLTl4dy/9KkFW9RvZ0vCUxhYhccAiEA/JQSpjpXRvCz4KAgysxtecIjatHju2334AKXKJuuL/0=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIGL72orNshRTDMbGJGCmlbu//0ctSi1Jdk/x+4IrOAFdAiA5o9gxgnrpHU5BzEKdexs48aDgvseSEcodrCeGSvnbuA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.67","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211214},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f99034d60a4f6cd850b7a97db6f52cef729a7c23","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.67","@hydranium/langium":"1.0.0-next.67","@hydranium/protocol":"1.0.0-next.67","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.67"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.67","@hydranium/langium":"1.0.0-next.67","@hydranium/protocol":"1.0.0-next.67","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.67"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.67_1789717924331_0.3188358445479118","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.70":{"name":"@hydranium/cli","version":"1.0.0-next.70","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.70","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"e9d7231f2835a9d18f696b33eafc6a7320681598","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.70.tgz","fileCount":272,"integrity":"sha512-pRpdOOXF3+b6CDgODsf7QNzwPVc1mLo8XLe2JLhgu8Leg0np5Ok203F0uTl5TgqQaIhfOcE8QRSWAzb2SZHGEA==","signatures":[{"sig":"MEUCIDY/LvuF1ENiVdMFp9LgMGpb9RCooYi/fk5HaCdJu3gYAiEA0YoFP9QPdo7xDYIWP8Uz9TDs0t22bpUZ+nVuXni0kjU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIF1rgQivyx2GoL3GlhQ9dlZ5HKk5ERlxEbZIYoTb/j5NAiEA/xdlFJno6aHy7wa/uv6/0djXvvYObT3wdmJwgWHynQA=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.70","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211484},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0f9f85df8f69447cd97a9215de36328761f79b1d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.70","@hydranium/langium":"1.0.0-next.70","@hydranium/protocol":"1.0.0-next.70","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.70"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.70","@hydranium/langium":"1.0.0-next.70","@hydranium/protocol":"1.0.0-next.70","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.70"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.70_1789729394103_0.6600443089299952","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.71":{"name":"@hydranium/cli","version":"1.0.0-next.71","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.71","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"7bc6234c229a311ac1aa1e128331ca3417411a6b","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.71.tgz","fileCount":272,"integrity":"sha512-HC91crUZO9kbXYYEZQqzBprhQa6QF+RTnYFFvplzK6kQgz9c40MmbjZ5cxirNi10hDsstp3a75tBWIUmlcdlPA==","signatures":[{"sig":"MEYCIQCcpQlqiPNH2I7i1ti5K1SqpTTDsx7PxsPzz0oZHvdPigIhALsNUys5hHbQa005GtxTJ7RqLmmz0lbvSWcdmQ8FsGdm","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQDdgxNrrDVGqy2SoRP4JHXy40eY3U0hJC0GOlUJFsj1yQIgD5zlJjkrk/Yi8BNUd5cDpZJkU8sJVX6BrRm2FJ9dqN4=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.71","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211484},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"604975444cb71f9dfbf2fd24c069530608c86941","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.71","@hydranium/langium":"1.0.0-next.71","@hydranium/protocol":"1.0.0-next.71","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.71"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.71","@hydranium/langium":"1.0.0-next.71","@hydranium/protocol":"1.0.0-next.71","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.71"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.71_1789730172096_0.07629762644174387","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.72":{"name":"@hydranium/cli","version":"1.0.0-next.72","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.72","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"dc6b534a2d6c35f27a415d1c42fd3b83bf8cc4f6","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.72.tgz","fileCount":272,"integrity":"sha512-vAmkEELqSfSkyOYtPUDqNudczfy6v4EnS8fxB+bZnhqS84+FID8G6u/H3XDPKQjJYMGj8BJUYRmyqR8XxtqZVA==","signatures":[{"sig":"MEQCIGKyUoyXfPySK+jXDlQ4vFaLpy4UcJCab6Tq5j3d69GZAiBcnirRpwEzsdZRL6qmNPPdeXxtceb9gKDGFZoCCsIjFg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQCxreLysJE0iPRsCarvBFcFYyQmmYuOn+BC1FJRieg9mQIgWlKezp7tX4UiqG3FsArCJOuwNl+L3ky8WCUnSrGOWDU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.72","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211484},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bb5c11b2465938e4a268f5fba57e1ef5ca5304de","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.72","@hydranium/langium":"1.0.0-next.72","@hydranium/protocol":"1.0.0-next.72","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.72"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.72","@hydranium/langium":"1.0.0-next.72","@hydranium/protocol":"1.0.0-next.72","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.72"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.72_1789735316038_0.8860670413013236","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.74":{"name":"@hydranium/cli","version":"1.0.0-next.74","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.74","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"82cd64dfc4275bf82ad67f677dc7aa1adceeb869","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.74.tgz","fileCount":272,"integrity":"sha512-Uq5PAZBJZzPGZ57EQYWv95548Vft2T9Xi1+IRJzlElyyJX7ldHN7P+fUw+KrGNvjWX0r+ikEgBeE2m1d/tEK3Q==","signatures":[{"sig":"MEYCIQC5vXHW8IOKoS/O0YsCPlVJ9QDxaqypSAr2mosuG41qxgIhANY/2nfoYfVwY9dLdrcTMlTis5uVBNNpniWUJMS2SLRJ","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIGK+kwQ/gCssGIqhau29z39I5jq93usuKZRiRSByXpjuAiB5SZlC1lC8okrrx0px+1mWMFWBMhwkSsDyGTMnmVaSDw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.74","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211484},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5c8600ba0b3c4f306d259bff5ef13f0498d04560","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.74","@hydranium/langium":"1.0.0-next.74","@hydranium/protocol":"1.0.0-next.74","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.74"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.74","@hydranium/langium":"1.0.0-next.74","@hydranium/protocol":"1.0.0-next.74","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.74"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.74_1789741269046_0.8165486227531733","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.75":{"name":"@hydranium/cli","version":"1.0.0-next.75","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.75","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a81d949b24be520244f79aca61ec1a9f2d4ef723","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.75.tgz","fileCount":272,"integrity":"sha512-F/fS2hOL1uKdYjOPz652htheL07fNDuP5O9hPJE9KobIlz89ccEL21iihtNbphBgVK/GEcHG0G59na31r2n+zw==","signatures":[{"sig":"MEQCIEB19PPh1YLI+qDuxLSYVVR/3sdTPT3PiXZOgsJNS3y7AiBOKs9XPZdaThIl6fYOjtAGhI721oF2zWuJ7c3NCiNfiA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQC5yuN2O5g1XdgeOFQbNCMbu0PUM548i5oq8qdSUWCDKQIhAPlmIc6yRDZmj6nFVyDDYkgX1AIejoHQHp0vspC494KZ","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.75","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1211484},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"8f3a13edc12662d38deeae09af0de9416064abb7","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.75","@hydranium/langium":"1.0.0-next.75","@hydranium/protocol":"1.0.0-next.75","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.75"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.75","@hydranium/langium":"1.0.0-next.75","@hydranium/protocol":"1.0.0-next.75","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.75"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.75_1789744173569_0.06542326383565356","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.76":{"name":"@hydranium/cli","version":"1.0.0-next.76","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.76","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"da836a5b0fc1c63631902fabb212cdf3f85b07a4","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.76.tgz","fileCount":277,"integrity":"sha512-Etl0YaB0MArp07/Mu93f3npMHz2XGBiZVFttviI7Xx/3ww8xuwR67pTcb6N+WhqXHpPPCfTbNpqq17K8JzD/oQ==","signatures":[{"sig":"MEUCIBJHi/q4eJjeHfpfVWirbwNwmMRslxpKdtk9eZ7DyyUwAiEA+zBEgNF8mbnbg7pZmi/vbHRvm0ioKZIQusNrt9mlefI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIB3BDnsarj27VAzCOrLwZjHhv/hPaTs4I6DvMWxTTS2EAiBGPdKxX0HOXso64TfoutLN0hPn0Rmg+sEGSdC3Pb+0/w==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.76","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223639},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0a65355f9d54e10db62c1c84e8e5af24e480a164","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.76","@hydranium/langium":"1.0.0-next.76","@hydranium/protocol":"1.0.0-next.76","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.76"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.76","@hydranium/langium":"1.0.0-next.76","@hydranium/protocol":"1.0.0-next.76","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.76"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.76_1789765028691_0.18554647286547543","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.77":{"name":"@hydranium/cli","version":"1.0.0-next.77","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.77","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"b1e7c1316dc6f02de80ee8c4f3db1717034b8e31","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.77.tgz","fileCount":277,"integrity":"sha512-TCbdU59vELewwPMMtloqWW99erwRmuuilJtZtQs3YImvBYZz8ZcEpWVBarLQf909VVENI0V+QmCWf8+Y3SXKrw==","signatures":[{"sig":"MEQCIB1fpXT9BBNDzDq9OoTzJVOquxsVpMAheA+iEHBmX+a1AiAyNc5Wlmsq0QWfSaY6MgduX0ytM2B+wzXs6DfIWJdUmw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIDfxUA25RmgS4J9TgZll/XUyIJfihMFGdiF66gs4J/AxAiAnQf+W1ob+CZ/pjNB8Gl/xgaOzsmJXRYtIjl8movB7EQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.77","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223639},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"04a881987b50020f2d9948d8b7fd8a2f56483007","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.77","@hydranium/langium":"1.0.0-next.77","@hydranium/protocol":"1.0.0-next.77","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.77"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.77","@hydranium/langium":"1.0.0-next.77","@hydranium/protocol":"1.0.0-next.77","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.77"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.77_1789768587980_0.21552653443244196","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.79":{"name":"@hydranium/cli","version":"1.0.0-next.79","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.79","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"244545f86b340784b453e59944fea1e2e1549c14","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.79.tgz","fileCount":277,"integrity":"sha512-WxNlkNXjJP9/pnT5knrEWy8alcQUjOtZnqAUaFzi/o174ZdSRFhNO7f4+ktkSDTJl4XDw7qE5TMyIj0jxwfmYQ==","signatures":[{"sig":"MEUCIQC+vY+VFC6WkJyD0GveLa7BzzkGEtMSKYlab41g57+AfgIgINXsPJ+QbWDW4rZ0wymQe7jTRl04Ai+Nlm1GkqfApcw=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDOzkjRgHDnqWMFJSbUWf7hCMv+klyGfYkRc72gkcVLOwIhAOFGbH7BmjXmF42TLc5dZYL0X220oH2nnuzZB7jDDB3P","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.79","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223639},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"cdd4ee08dac5ead84462ccf4e20b34a06b37953f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.79","@hydranium/langium":"1.0.0-next.79","@hydranium/protocol":"1.0.0-next.79","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.79"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.79","@hydranium/langium":"1.0.0-next.79","@hydranium/protocol":"1.0.0-next.79","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.79"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.79_1789916550146_0.06780802522608997","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.85":{"name":"@hydranium/cli","version":"1.0.0-next.85","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.85","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"9778016430cd8ddc1b5f2ab72cb507b93591a78a","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.85.tgz","fileCount":277,"integrity":"sha512-L3XClRGruuDUs0dCgMFRt01rD6B23Fxu3uHNg6EJrlOxvW3nUk2skIa2OlzMxBsybJW2iY4rgZsWYhBoWtzLfw==","signatures":[{"sig":"MEUCIBgYFuSU3kVhkSPcfD7pUyzSSCq3OsVC9UT20D3TtCSRAiEAohpZ4O58SQEZAA78fLKH+ybrTua1SGi5sReKCtxnPzY=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQChB9y1IlXxuudh9kVb7EvK8/0aM6L5gyEjIv5WgksVwAIgEGh99w9XU3WhnyjyQZNwSLU1N/k/gfYl0dByoTw/GN0=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.85","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"fe5acd004ce128c9ab614e06bb4ba246cfbf89a2","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.85","@hydranium/langium":"1.0.0-next.85","@hydranium/protocol":"1.0.0-next.85","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.85"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.85","@hydranium/langium":"1.0.0-next.85","@hydranium/protocol":"1.0.0-next.85","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.85"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.85_1789939420841_0.6161863766400795","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.86":{"name":"@hydranium/cli","version":"1.0.0-next.86","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.86","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"523e306d4afe2c6bd1445eb68da58d5ea8b1859a","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.86.tgz","fileCount":277,"integrity":"sha512-lCBxsBcSoKXaYGU7HAvYWRpy3r+0XCHmmnBbIIaTDpxzf3IsIxg1XiPWPaPGPMoCkb3HYdogQmLsqoSRfUSULg==","signatures":[{"sig":"MEQCIHgV5WoXoRwzhEbUe4VXOXv7P2ApXq4deRrooFaLjfl2AiAhLnq+bFbMCVKV8bBDITjS7BIrpPkUqE77KmPnL5GbVg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCICeLTy4ZbznddPA4yHgiCvPw+NwkVvc3G2qZ9i3wbGfBAiBrDFka7gYYASNPO67fQDIl5cJNNJJmwHdaQzDz4HMwjQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.86","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"7cf16c55fe7183e87b9a24b9f01cb76ac6095603","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.86","@hydranium/langium":"1.0.0-next.86","@hydranium/protocol":"1.0.0-next.86","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.86"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.86","@hydranium/langium":"1.0.0-next.86","@hydranium/protocol":"1.0.0-next.86","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.86"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.86_1789974833281_0.3524674339717","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.88":{"name":"@hydranium/cli","version":"1.0.0-next.88","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.88","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4f5a4673f071d7d2d33194e95983f24c1f835fe8","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.88.tgz","fileCount":277,"integrity":"sha512-9O7P8/bR//n0VNOFdpqpQzf2YxoMLpcCATztlpmKit10k05Fsw64kejdn/GH5E4ezeaRmSjAxeBcrEzMlBC6xg==","signatures":[{"sig":"MEUCIEbHFmcgFu1+SMeICLkumBYpdcVHv8EaNAv1nuXgAoNqAiEAtfdcVRdyCiYPk0ZgiLHPd6Fi9d4fer8xaxHOk9h55Ow=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIAuMOFPc3I+pVWrZwmKTq2pErX/fT3iZMt1JmtBMOrYWAiA1O10eA9J18yK6qwH7gC22x9+JlKJ+Dbf0DlcgG2i4rw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.88","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"b3ac9a4c60d83edb3c0e53e8b8afbe465607331e","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.88","@hydranium/langium":"1.0.0-next.88","@hydranium/protocol":"1.0.0-next.88","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.88"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.88","@hydranium/langium":"1.0.0-next.88","@hydranium/protocol":"1.0.0-next.88","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.88"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.88_1789979837140_0.7798004621613781","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.90":{"name":"@hydranium/cli","version":"1.0.0-next.90","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.90","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6ef89883aba0ad823b8c95ee59fe4b34dc9f33bd","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.90.tgz","fileCount":277,"integrity":"sha512-FEDr7NyVq19WWziG71LCTRA/XMsMFTziMqe/fe2pbwYiqtQzciJ8HEcNphFW9GFlznSMDC7Km6XFh2wCSnIJnw==","signatures":[{"sig":"MEUCIBivve0cN4xN0zXAIXb5dCMG23Qa5wInyAjwH++Ie/rOAiEA0Zw7YXTLxKY2StuWJWBwpbks1FNRtwqOmghPf5aZXN0=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIA3eFL60QwF0tPjilG/C+TDyjU+hsn8XoxQNyLuX37KcAiEA33EgcqBUK1B5hPoIu11zF46coZseNUV6/l++oGbOP5Q=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.90","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"3e2ad81fee111848cc198c86e3ac6aa1c76a0ecd","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.90","@hydranium/langium":"1.0.0-next.90","@hydranium/protocol":"1.0.0-next.90","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.90"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.90","@hydranium/langium":"1.0.0-next.90","@hydranium/protocol":"1.0.0-next.90","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.90"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.90_1789986151804_0.9710626755459852","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.91":{"name":"@hydranium/cli","version":"1.0.0-next.91","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.91","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"086ba017dec3f5a9bdabc1cbc3d2f55d87dcef1e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.91.tgz","fileCount":277,"integrity":"sha512-4o2My7hzgi3jTtYZa/ouWZV5Z3l2R8veuUj2DCXKhO4e9MPbvpU2Drrbx53wnWmhu/mambK97pj5AjLANwOGiQ==","signatures":[{"sig":"MEUCIF1nJRdSndH2KvQf/20CbnLRSzfga40qAV6JmpbqbGExAiEAtrCB1n2t0vDVi/FXX35IfwUNskuvmsZOuio9kfyiqsI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQDcNxwOlZrglOm7uTrCAhukcu69+mh8GFhvO4RNYbxc6AIgMNcsMWudnvv5csxPGNbA3tUiCv4tDxXvGbdG5OCkG80=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.91","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"4f7b482f48f14b703dc2756dddaf41498ff0e628","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.91","@hydranium/langium":"1.0.0-next.91","@hydranium/protocol":"1.0.0-next.91","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.91"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.91","@hydranium/langium":"1.0.0-next.91","@hydranium/protocol":"1.0.0-next.91","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.91"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.91_1789986871146_0.25555112591322326","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.92":{"name":"@hydranium/cli","version":"1.0.0-next.92","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.92","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"b1976aca9c92f03b480c0fb925079ee5e8aa7169","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.92.tgz","fileCount":277,"integrity":"sha512-e62O/ASgY5F9/YrReobhhBsVF+pfYD3t/586b2lMkZUArDJghsdPP60jP6X5+2GRuCIgYAMWkTvhia4c+VoEyw==","signatures":[{"sig":"MEUCIQDBs4yWEpGutzX7mvUbESoFn5NyaIfWNCvUqkC7S0okqQIgSPBy4DQ1cEcfd6BoOulzjqXwmvjcD1afp+aUatMwnhU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQDHXRXXal8WAkn09WOl52giuVplsPWXlA5oj5+jIbo+IwIgD0bhK7uQ2HkFWsiCIuf2jn/Lulq9fUErKNbtrkE4gV4=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.92","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"e769e1181a2eb1e5f024f93378346fc6439ed20b","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.92","@hydranium/langium":"1.0.0-next.92","@hydranium/protocol":"1.0.0-next.92","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.92"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.92","@hydranium/langium":"1.0.0-next.92","@hydranium/protocol":"1.0.0-next.92","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.92"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.92_1789993042561_0.49655761419325795","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.93":{"name":"@hydranium/cli","version":"1.0.0-next.93","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.93","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"fac64508c050ea411e82ee311afb996dca331cec","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.93.tgz","fileCount":277,"integrity":"sha512-xnWj1VA0jkudL9WEiDyHdMN4IE6KiHJvgVt4YDPSrFQmOmqyMWiEwC6qMVmpy0r9KkVQJD5+23opV74BgB8gSg==","signatures":[{"sig":"MEQCIAMgZvhVp65YO3/4bnoKI1l5ZTn3j3vcAeOGuB1bnGkCAiBkmMlp4sqC7gElpnjdQkVItCo0r+H2VTWS1rqOxbiG1Q==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIBxr5MGfZNFHAAh8eZt5cJ9i/t8yF3qi8wm2ZYijjkiDAiBE60zpGixqQwew5UJ6BgvizNi5GmoKktMPUVAMIHl+DQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.93","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bdbb81dbc2d8d1369dffbf206d420cb67502da72","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.93","@hydranium/langium":"1.0.0-next.93","@hydranium/protocol":"1.0.0-next.93","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.93"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.93","@hydranium/langium":"1.0.0-next.93","@hydranium/protocol":"1.0.0-next.93","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.93"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.93_1789996394778_0.39623770954199666","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.94":{"name":"@hydranium/cli","version":"1.0.0-next.94","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.94","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"59c2244e8bdf0c32b6591eec3725a9932324e325","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.94.tgz","fileCount":277,"integrity":"sha512-U1GATtAt2zTczf7MspQ89M6PhiW4v/h3Gpnry9kfRWfGXxk+23Q3cuNvhFqvb4oBBLIf0GdnfwrcG/asZvJ6hA==","signatures":[{"sig":"MEUCIQDOJeLsARyF/nR3DB4jhfdTTXQAZO+hwI7MJVtG64jQ+wIgVYg62VFYyStrhgeLiiKOIfGMnwM3Hpv2UYGxs5wdUog=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCICd1zMMkr6GD2NsGiLDi07/LTussqyCPoOC7vsK+GZ1fAiBSz/+VHsLHsF3tj2QzmPtfBtT3yHkkIkSMwo5bawVOBg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.94","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"7e8b9eaf891f3ddea6d7c6fe4433c80d9d0b7f87","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.94","@hydranium/langium":"1.0.0-next.94","@hydranium/protocol":"1.0.0-next.94","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.94"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.94","@hydranium/langium":"1.0.0-next.94","@hydranium/protocol":"1.0.0-next.94","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.94"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.94_1789997684983_0.8857717382752563","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.95":{"name":"@hydranium/cli","version":"1.0.0-next.95","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.95","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"0d9ddf272c856e5e53bd1597fec0662d80488a57","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.95.tgz","fileCount":277,"integrity":"sha512-WdKtsqitsd/hP2GsVf/VXo+q5mfWX0ZgXptq/1Q0KMHXMb6VjtSlPL5bxuLh37fET1z2cFzpUNeVc8K7zzuNAg==","signatures":[{"sig":"MEQCIBzPCahmFfed5p7pW6fxrl7HHnCrlNyX11FktXrkoS2yAiAZ+crUubw79ZYOFBBaez0oGaIMNOLhr5I7i7hQwDgsJg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIFXKEsMZCcGwzXUPBirc6xJsK8eJ4ZLhHCcV2s9GC/AZAiBEgL5OVot5/9UwJ5sy+teuVr7l+GpErfjQ1C/wWrnkXw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.95","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"4192a93d475509f570e4130a8b4904ce62dcd5cb","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.95","@hydranium/langium":"1.0.0-next.95","@hydranium/protocol":"1.0.0-next.95","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.95"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.95","@hydranium/langium":"1.0.0-next.95","@hydranium/protocol":"1.0.0-next.95","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.95"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.95_1790001318854_0.7960287445169925","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.96":{"name":"@hydranium/cli","version":"1.0.0-next.96","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.96","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"9a644132b803756320c9048704f6d76dc2c2c6c7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.96.tgz","fileCount":277,"integrity":"sha512-qcmKCZd+W8LoqAfJf7PtiN3wwr+gl/OOZ0W5124WUfjUhYDZIplYOcSzU3BhU01rDnViPcblGqR80rtYGpRklA==","signatures":[{"sig":"MEYCIQDAWApiEg/CbESWok+T6T2A4Y2hytj2s5SSUwyyM/NAYwIhAMkvXmfTJE5DrxkdzDj8YCbTzYoBvlSU88A3X+uXp9IU","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQCewY+A7HQPjERiliDThfyAGxHKCnYx9YXb6iChKmZ/AwIgIa/g2tbn/FTYevC79SYmeEJptmLdZ6xBK8xt7AT35GM=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.96","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bbaae7432df9468cb7621b2b020ceecf28802a8c","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.96","@hydranium/langium":"1.0.0-next.96","@hydranium/protocol":"1.0.0-next.96","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.96"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.96","@hydranium/langium":"1.0.0-next.96","@hydranium/protocol":"1.0.0-next.96","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.96"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.96_1790186314728_0.22101927324614","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.97":{"name":"@hydranium/cli","version":"1.0.0-next.97","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.97","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"60305c1066207a037bb331857a3048e711337ad9","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.97.tgz","fileCount":277,"integrity":"sha512-7c/Xfx1YwpPMeOK5cT2pTZfZYdkS7Gl3BR1BVGjNLRMYQ66tPWtMLgfZ0Wn3aSTfx4aeQhPJK7MoPX3rjrBJng==","signatures":[{"sig":"MEYCIQD6ahP+n0Z5EOnzEB5V/+/wiXJihndRtGN8mKl5qru41AIhAN31AMbI4uektNqwQgpC3jxfUwHLamgvH9UTcHN25HNZ","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIDimrguH7eWsaZWbri43mWILWFC+bIrJMyD8RmGXW8SqAiEAz7VLBQyJp1s6dVaQOaFs+jU4inaSh2IJ0YrCgX9F5NY=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.97","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"140f23ddeb6416eb5e00cdc3885da83676a7c778","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.97","@hydranium/langium":"1.0.0-next.97","@hydranium/protocol":"1.0.0-next.97","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.97"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.97","@hydranium/langium":"1.0.0-next.97","@hydranium/protocol":"1.0.0-next.97","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.97"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.97_1790186594919_0.5749344358958519","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.98":{"name":"@hydranium/cli","version":"1.0.0-next.98","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.98","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"04ebc439e230f4c1c828a0ea1d940cf3c718d844","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.98.tgz","fileCount":277,"integrity":"sha512-OHmVWpwGtNijsD+qOCZ0h8W1aEGh+EpE3ZjxPQzhnORJC17w4NvcsCm9T5jpVPAvEOW/0dqH2FSCG6ZFOOpD+w==","signatures":[{"sig":"MEUCIQCZbNfh8xvm1sAu0XN4XbfAuoEkh98aTmVt0Q0M39dR+QIgHeWdOSUG7Pcu46ZPZd80Enf+VgC1OzYCLoydYHg1DoI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIFiyS4q6AC5cLnkeUfRMfFrMGAQYWSn7Dmtlpyh+tD6MAiA/zn6qL0xMawPT9kqHSgS+BEqZ3w1VuldUZOaFzlYLWw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.98","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223763},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"b3e6b749d5fb8f6f44f4f242877ede97ff9b8707","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.98","@hydranium/langium":"1.0.0-next.98","@hydranium/protocol":"1.0.0-next.98","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.98"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.98","@hydranium/langium":"1.0.0-next.98","@hydranium/protocol":"1.0.0-next.98","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.98"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.98_1790187240620_0.89389918354175","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.103":{"name":"@hydranium/cli","version":"1.0.0-next.103","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.103","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4a26ec8b137ec2f830f6e805b09fd4a3af001092","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.103.tgz","fileCount":277,"integrity":"sha512-uDem26iRwzPj5xdymqHSAuXqUD+JkiP9z1qQs7huazVmN5QTJ6WgPk3ewXw05uzOwdvCG58d8CAXhNFR9a5BRQ==","signatures":[{"sig":"MEUCIQDvIPDPmxBFbTTN1+TpLQKlp8zzOC7nWf8bRFvazDLQSQIgErzEre0RliFqajDCDtg5rAoMWnXIfeL57SkE8OEtvVs=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIHPTJ6aaGPSo7PLbfczXmkfHP0DK8pTsmCeDCcCh677lAiBe49mWqPEVybSlTLgv+fT4NRCrLu9ooyzJY+N/qRyADQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.103","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"1b5fa3a4791e3d999e7b3b36db935365b78127b6","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.103","@hydranium/langium":"1.0.0-next.103","@hydranium/protocol":"1.0.0-next.103","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.103"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.103","@hydranium/langium":"1.0.0-next.103","@hydranium/protocol":"1.0.0-next.103","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.103"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.103_1790188604509_0.3163037107617235","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.104":{"name":"@hydranium/cli","version":"1.0.0-next.104","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.104","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"4f57e4e90d751c668b64be7f19f22fa196ebf1b2","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.104.tgz","fileCount":277,"integrity":"sha512-EFszVpRs3rwRkWCbsSJLjxBeVlhVizVdh5PaKzjc7Sm1/oEEEcZ248OewZm7PZXivabJebLoyKoxobJo5pslow==","signatures":[{"sig":"MEUCIGC85NMO3VmDie76EvLzWqrV+yQjq4qGGlN6vnrTLciWAiEA4Ll6A3YPSM94ZJsU0aP2ZRFGXGsx1PMFGoXyL+0FqyI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCID2OwrNc6y9E7st+y3RMsu4EwZ92nL/8i8JLRs+zdT5OAiAiDgr1AnnUG4q54YSkz7/PSsL6uifPKV5OYPXnBkgP7g==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.104","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"cb070e687e0080403741b70131c33b6bfd2ad561","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.104","@hydranium/langium":"1.0.0-next.104","@hydranium/protocol":"1.0.0-next.104","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.104"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.104","@hydranium/langium":"1.0.0-next.104","@hydranium/protocol":"1.0.0-next.104","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.104"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.104_1790189145972_0.4887862791486639","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.105":{"name":"@hydranium/cli","version":"1.0.0-next.105","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.105","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"2205fc1333fa58e8514f9cf0743200f6fe051f23","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.105.tgz","fileCount":277,"integrity":"sha512-NZDMgo+a7PlbfjF6hxg1dqUSpVBJyPWd/VBtzGOvLnwr0f3DRb7t8VW9tmBepFRRal4r9ofPYKZ0sWQzvOGGLQ==","signatures":[{"sig":"MEUCIFcF/GwUPuiZKSjSu/sEi4R+szdLLDUNGjIdnEC+CCfuAiEAxrKyJfYZ7tSrVU3N6M+Nv6LaqZlmWOGsvhd79OMqKv8=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQCAIDX61j74/GGTqNj7l+5GZ5B6dVbiAIBbfd2P49C4/QIhAM9S5ewiuRTM7f7ZOT3ZVpxNAIY7k+Vf/7bQYjhG89su","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.105","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"1f038ff518ccc383ab0487c5d29315b803c8cff2","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.105","@hydranium/langium":"1.0.0-next.105","@hydranium/protocol":"1.0.0-next.105","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.105"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.105","@hydranium/langium":"1.0.0-next.105","@hydranium/protocol":"1.0.0-next.105","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.105"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.105_1790189789101_0.10065119727839456","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.106":{"name":"@hydranium/cli","version":"1.0.0-next.106","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.106","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"bf19601e0a8846263b7c22ffe6a80f6ec44cc404","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.106.tgz","fileCount":277,"integrity":"sha512-HUDlJv2o/Dk0CW4/ztMOXTQtcTxOxhwo5VgpTx+sc4xzx/K/StwV41Ho8h7Dr+nW4fA0NPbCKJbHdkXQC9Vy6g==","signatures":[{"sig":"MEYCIQD1nlqLc6QEq367WKAwhjB6Js1yTna1e8onbELjg8tYAwIhAL9YyJzAVYgiEXt231jbL5CeDV+bN4OViPkUllMsNK4F","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCICpMPvlpjy7fdnlU1IMaU5+nSJ5oKKkbITCM72pTA5IxAiEA32oSSrqP+OJlBviBjIsIwvQbq05S65f+vEfuJmiZ1ew=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.106","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0b4ba0bfb1f64ffc97300019781a001d7c7c41a4","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.106","@hydranium/langium":"1.0.0-next.106","@hydranium/protocol":"1.0.0-next.106","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.106"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.106","@hydranium/langium":"1.0.0-next.106","@hydranium/protocol":"1.0.0-next.106","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.106"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.106_1790192724088_0.2549464192792479","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.107":{"name":"@hydranium/cli","version":"1.0.0-next.107","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.107","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"bd12d80508873f4056a53d82243e385c1c47a34e","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.107.tgz","fileCount":277,"integrity":"sha512-7kxB4nQ1KnLWNmLb3TasQXmNIZKw1CdyJONzYSjfu3wBkBfaMCAAMYdQPXKkb2mLDY2vdQkHBNXVbUR8n4ck7Q==","signatures":[{"sig":"MEQCIGa6VxYeqDD2zT85TAurt01CXm40ISJY2AVFNlQd4NIKAiAyFc3Uka7D47fTQr67NAvKlOeIgpG3+O49ElYqyHzrpw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIHGDcFpjbNWMY5pzu8CHyACu1Pz5JfLDLDaB+6YY672SAiEAz8Gbs+Lcmm0RO3ifmMiRMRp8+F+RyHmXE/M8BiP/GXI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.107","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"bb529cf424502390902ae349b301179ebb937ea8","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.107","@hydranium/langium":"1.0.0-next.107","@hydranium/protocol":"1.0.0-next.107","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.107"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.107","@hydranium/langium":"1.0.0-next.107","@hydranium/protocol":"1.0.0-next.107","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.107"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.107_1790195317308_0.2310620600172375","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.109":{"name":"@hydranium/cli","version":"1.0.0-next.109","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.109","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"2e051769e5cdcd42c21a6d1352b6d111c74be5ca","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.109.tgz","fileCount":277,"integrity":"sha512-Io2/ue5HQkuvgpcfLCtIFwnpN3GSHXTrEpS+9X99ggvvZHeXYzku9mO2gcdqq5brLyP1wwYa6HY/NM/SZu54AA==","signatures":[{"sig":"MEUCIC3aysEXZso7/FfcQpKkO8PgxKRBD/FbJQWl34PBqyRmAiEAx4CnxAw8dLdkIwzZXbh761NyuX7OVBCC4nXzzwptFrc=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDq7gsyaefJXMcTNleb5TNTX5FM9kpEUDTa8p76gMlC1AIhAJqWwKbFYIojOWBWR6JItKPX7gZhIBmd+pqhl7Vyis4i","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.109","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223772},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"137baafcb95589fab3a54a6645803d387b81e8a0","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.109","@hydranium/langium":"1.0.0-next.109","@hydranium/protocol":"1.0.0-next.109","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.109"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.109","@hydranium/langium":"1.0.0-next.109","@hydranium/protocol":"1.0.0-next.109","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.109"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.109_1790204390178_0.4732977867075494","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.111":{"name":"@hydranium/cli","version":"1.0.0-next.111","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.111","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"9131569f911039f5278c4a0d8f7fb88e3b10e01d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.111.tgz","fileCount":277,"integrity":"sha512-WY1p7XgWwu4riSQ9H5c98/nIT5XLqPoVY4K+SCiDtjSvw7h3OvrU+mx6C2/QIVB9VSVLAMYcxWWpDFN1IVx+aQ==","signatures":[{"sig":"MEUCICbS0CFhoqs2EJOYM5C9RkoomrQQZsiG0FqBna0+eFe+AiEAr/8Cr9g9ArR51V8JDVt+jN7mjqXZJmYCmGyfCb0NwTA=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIHYsmsaBvFl29Pl1LhsKaWPa2IBr2ojXGoFporBqkccOAiEAofC+vKOG2ZYviG5YAbyeJwyACW57SzmuYjP/vrzz4dg=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.111","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"8add1d2ad3dbaeeff870b21f3bcf13361a37e28b","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.111","@hydranium/langium":"1.0.0-next.111","@hydranium/protocol":"1.0.0-next.111","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.111"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.111","@hydranium/langium":"1.0.0-next.111","@hydranium/protocol":"1.0.0-next.111","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.111"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.111_1790256532298_0.7093151010770977","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.112":{"name":"@hydranium/cli","version":"1.0.0-next.112","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.112","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"34034598c9f246bf752d5cd385d02be81c42a1bc","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.112.tgz","fileCount":277,"integrity":"sha512-xj8EmvIw2p2wx3uvxcxMwr5bNMNBv9Cdq+2FdDmCCcqjws+ma9RCqkiYNzbeoW5u8ky8e2pRGfbZy4NSK1CQsw==","signatures":[{"sig":"MEUCIQD+O+vGDK130/ujynnQ7VxuzSOsZ0PBQ0psKYDFnbivcgIgQJIy+eoHClH9u6v52e/kWHifwnGeFFKdA0rYwNAG+mM=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDKTGDD6sXcFHfp6a3cvJ44LpoKo4X6Bd5Xa2la/FbhIAIhALZEY0WRfJeeAOJfZXFaYx2iOqE0MGTYtWTdnTPmYuFf","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.112","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f1f9ddb7e3bd21283dd982005add36ac4ad39859","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.112","@hydranium/langium":"1.0.0-next.112","@hydranium/protocol":"1.0.0-next.112","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.112"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.112","@hydranium/langium":"1.0.0-next.112","@hydranium/protocol":"1.0.0-next.112","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.112"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.112_1790260546188_0.4765706805915255","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.113":{"name":"@hydranium/cli","version":"1.0.0-next.113","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.113","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"be06452903622a11a638be7906612ef62fc8a89b","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.113.tgz","fileCount":277,"integrity":"sha512-DjDU33RqtY9HMPS3uwrSuLRN1Kv06rkTYh09hwkdNvOSc4bIVaV0T0KruaCOIRmlSIr0gqLL9tIOzNz4jJiKWA==","signatures":[{"sig":"MEQCIHzDr4mbzdm/pfslesXaX6GaD5gCfxQZmyKBov5pi/CoAiAbFsHT0NfEtZkRee6tbvMjsz+2jrU6WxajzbjD0w8pmA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDTDTEosLCgu/SydT68/eZZ5GvQ0eZNW8tDtYLv9ClWXQIhAOB4t03EUAkkOv+31VzzxC9bLrbUGQ9dLn/mYzdJexSK","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.113","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"c27a580af54cc7f72ea5f6363e3af6b86adb08f2","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.113","@hydranium/langium":"1.0.0-next.113","@hydranium/protocol":"1.0.0-next.113","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.113"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.113","@hydranium/langium":"1.0.0-next.113","@hydranium/protocol":"1.0.0-next.113","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.113"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.113_1790264282175_0.9591541435324822","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.114":{"name":"@hydranium/cli","version":"1.0.0-next.114","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.114","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"cfd2518f62eb8c642e1ca475655acaf39106853d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.114.tgz","fileCount":277,"integrity":"sha512-7GrJBA4jshRqn7gLlOZ3430A2gVJ8Um5EI9C6xxmGGEWJfIyfAXzRlfqpxnkql09LjnN20HMtuGg71yUqjJqLg==","signatures":[{"sig":"MEUCID9/ahCW65br2ztNHYs+y60caRpvOMvm/USXFIBLnbjNAiEAiG2cyqNSvhpjA5/m2HrcS3nZVMsaYWzSwFDdwIN7Go8=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIG4u1igDQ7JFG6LBGTDA7bm24VX6PIRUY0uW/hiV2zVdAiAi5xqWzI2ADfFYmDvBre1psQcbxe9oTOS+e6JESYpjXA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.114","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"212f8bb8490512f4e60a1f153659efeb7b399d53","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.114","@hydranium/langium":"1.0.0-next.114","@hydranium/protocol":"1.0.0-next.114","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.114"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.114","@hydranium/langium":"1.0.0-next.114","@hydranium/protocol":"1.0.0-next.114","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.114"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.114_1790268253710_0.7596788566839301","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.115":{"name":"@hydranium/cli","version":"1.0.0-next.115","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.115","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"52fcdc218a4477b9bcc518ae212b31f18bfdc250","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.115.tgz","fileCount":277,"integrity":"sha512-Lj0WpguoT6i1h54Rm+OA4Tylb8X0IiE1g+CDeMyrzHZ1bX7NScnZNfpp8ThJwnDcjZvSi1auodPxG8YskyGIWQ==","signatures":[{"sig":"MEUCIQDLEKODV+EF1KIgLczrAfR7KiJL8Z+gDlyQ1xiQL9Dj8gIgbhUP115xlwwQrANIi9LYiydmS3FKuWWgfWEcLTPDJrk=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIH8alFzqDNxxPw/BYpTkrQ1YxDu2cbtBfBibWXe2hw3mAiEAzjtY+ZNGsMbrjSe4lKcQRqnpV5ocEj26t9vrPkZi19I=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.115","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"eeaf6fbeb80edb859679b15b636e83233e989b9e","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"oidc:4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.115","@hydranium/langium":"1.0.0-next.115","@hydranium/protocol":"1.0.0-next.115","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.115"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.115","@hydranium/langium":"1.0.0-next.115","@hydranium/protocol":"1.0.0-next.115","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.115"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.115_1790286445349_0.10474115527258343","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.117":{"name":"@hydranium/cli","version":"1.0.0-next.117","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.117","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"26e564afad4989240ec56566dc86577c8b96cf39","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.117.tgz","fileCount":277,"integrity":"sha512-axwLTi0o0gRFF/Pg3aTAZJU3LWrTVYK3J2oWgXXvb7/HxjIQoTzwHx9OSbU1/+x+WGmelkcr5+lNoCQa3MHDHg==","signatures":[{"sig":"MEUCIQD3I/OUz9iHT5OdAmJtwB+5y72vGQM7/Ji49l1oIdgzMAIgYa7ekhGc0dWsfmSxVGjW2YJQC6mAxjAhfMrP42n5wNo=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIAE2epZh8Nj48shHxnvVJPdt+9NvZcosYcjMkslcszWcAiEApLwnGH7/5HbAQLtYiM3/H5ouD5+rmSHnQxQFn3UdU1E=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.117","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1223876},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"45a1a35a68595f731aac6bd16d109d3226827521","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.117","@hydranium/langium":"1.0.0-next.117","@hydranium/protocol":"1.0.0-next.117","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.117"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.117","@hydranium/langium":"1.0.0-next.117","@hydranium/protocol":"1.0.0-next.117","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.117"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.117_1790631859078_0.33042605199359776","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.123":{"name":"@hydranium/cli","version":"1.0.0-next.123","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.123","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"5edfb1eb9c996f48d88fa9388b308a8fd75d7ffe","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.123.tgz","fileCount":277,"integrity":"sha512-vKpI7Q9YvJbwYuVbEPt1peeI1LvBFviS/+A0OqqhjWX/JXqPnxh56rY6Ss40erOW4rHPQu0kfLfBcKTa/kACcQ==","signatures":[{"sig":"MEUCIQDKAQntyn1I+R29aOJL8wPXwQSAvc9KMrgJcZFt1InW4QIgdEOvgITW+mhjuJ0+CoKHhd1mjWDiapF2/fR/Gvgb/Gc=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIDPTGhlIulLTVrTpLW9J4ln6r/cVqWoRB/S0NF6l1LVIAiAsHF6ISCon9b+4iP/GFQ9pjjctrfB72pMNdCvET87vUQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.123","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1227936},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"6b7cd61eba0925df8150ed0a438804dc43c24319","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.123","@hydranium/langium":"1.0.0-next.123","@hydranium/protocol":"1.0.0-next.123","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.123"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.123","@hydranium/langium":"1.0.0-next.123","@hydranium/protocol":"1.0.0-next.123","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.123"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.123_1790633376212_0.5559319454729077","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.127":{"name":"@hydranium/cli","version":"1.0.0-next.127","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.127","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"08bceba3941818ba2f1df30e7e25d84e0b3b9d75","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.127.tgz","fileCount":277,"integrity":"sha512-+JKs0eVCbcDZ3/u6uVdm4KDtjcZ0Ob8kFz0gcr+JpfD2AYeSHWt7zls6AjGXcVt8ykSllA8RVslzDPTIBHfh7A==","signatures":[{"sig":"MEUCIQDBMu9SOuOli15F4CXzBeKc0SL5nb0aCy5LV8ppyVADVQIgKXzrvPRACcuyfgFn1XkeD5/O7eAPF1Kj0NFsAZr6Gu0=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQCXGjEbA/egnXPSnuJXB/lAbijNntZx7485AhkaT7siAAIhAJDoUJwopZckQszkA1sX33p2SeSOjl9J+B1oHfPn1p26","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.127","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"11cf902498b55aea98fb0c9fd0cc8788c7518539","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.127","@hydranium/langium":"1.0.0-next.127","@hydranium/protocol":"1.0.0-next.127","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.127"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.127","@hydranium/langium":"1.0.0-next.127","@hydranium/protocol":"1.0.0-next.127","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.127"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.127_1790634874739_0.0070794973375769565","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.132":{"name":"@hydranium/cli","version":"1.0.0-next.132","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.132","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"5e550bda6e8c2f026ad6801c66abf3c031bec604","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.132.tgz","fileCount":277,"integrity":"sha512-Z6Veo5E7SXwAFJWlT2OjAzMDAu5ko6sBssFAORzcoBSmMSdy/Pt0yix7xayS0D1Sn1Z20ZPn10HA1lMyaBiubQ==","signatures":[{"sig":"MEQCIAQv3Q0PWiA9YyDl7pXWtY24ODBQ8xGPK/uFdhoa6X5NAiAW4D3o/BtXQpBJufplWc+8RQsQl7wDN6n6cJlxV6Xgqg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDW6HVpeopzSlImmybavQ+BM4oNHR26jWqojI//kw6pLgIhANCmMpHnI6iyaoCzlScZ9oB7eDvl4QlT3vEQCoaxx19J","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.132","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"27dbc2470c7b60e0097425e4c4df6922ad9a22bb","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.132","@hydranium/langium":"1.0.0-next.132","@hydranium/protocol":"1.0.0-next.132","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.132"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.132","@hydranium/langium":"1.0.0-next.132","@hydranium/protocol":"1.0.0-next.132","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.132"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.132_1790635633640_0.7832748605584017","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.135":{"name":"@hydranium/cli","version":"1.0.0-next.135","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.135","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"f721b690ac7ce3392e4986e37b79f403c8564910","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.135.tgz","fileCount":277,"integrity":"sha512-2SPdmA8jPxXQ0s1+w+9aDZVdXDIqcBCMHHmESFFBwjtDGA+nLnd4zWLatHpT5xY2zsgZqih5sbt67SuNKw8mdA==","signatures":[{"sig":"MEUCIQCoyRaRDWVSdndepM8QHDxYaeWW6/SNsECsxkuTJIlwAwIgQ/mSwjdVgSWbacVbLCqIF73FB6PoyEd+jUgVux1oz6k=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQCv+P5Dno6bbKJyeorZCucTh8gh7fcLM+RFpMef3XToQAIgWxigR4lA1RKpmlX8Ql/D5oizEuiBDamPIS49Cj0tW2E=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.135","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"cf87c80702f9ec9b1c58bc1f3499cc87a8bd3ef4","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.135","@hydranium/langium":"1.0.0-next.135","@hydranium/protocol":"1.0.0-next.135","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.135"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.135","@hydranium/langium":"1.0.0-next.135","@hydranium/protocol":"1.0.0-next.135","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.135"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.135_1790636093478_0.19273957419857157","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.140":{"name":"@hydranium/cli","version":"1.0.0-next.140","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.140","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"89b1e1b744b10fd309582290d10c0d12f359869d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.140.tgz","fileCount":277,"integrity":"sha512-mVa6+ENLtRT6LX2+/W5tTrC42gXwFg/OTKV8u4uMHze4iZRPu/J4v4C7sGlGkbgrDH4xp6H7v7H9+FXBtcO/gQ==","signatures":[{"sig":"MEUCIQDhwDwOQIBV5BCZL+3Uln/sKiVqWaqkuONXcmC1c9BU7QIgNQUUNBzS2FhTXORqUsZnD2n3KJyEXoSI32O+hpcz66c=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIE8WQqjaoiyORCK04XsnK3a1Bx5L4L0688yqZ+w2RzbjAiA3jz2/u2yD7uwXgICHAip7W0h5uzS2noPf0VCQzdf7zw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.140","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"427719cb511b0dcc901e7813ba7fde37573c6a7a","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.140","@hydranium/langium":"1.0.0-next.140","@hydranium/protocol":"1.0.0-next.140","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.140"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.140","@hydranium/langium":"1.0.0-next.140","@hydranium/protocol":"1.0.0-next.140","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.140"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.140_1790636624912_0.003650480126454747","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.148":{"name":"@hydranium/cli","version":"1.0.0-next.148","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.148","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"5bd63c1519420c809079335fb8fc88eb13b29698","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.148.tgz","fileCount":277,"integrity":"sha512-uwQcToTBujimXx3d2datUZk45s3Y6Q9wcnOoEpZZ8f93f6aG5NjXfCMD7J8zrUW3vTMca//8duu1wXYD9flG9w==","signatures":[{"sig":"MEYCIQDdeCBCX+24W78jZpLz/LF4UihhYrCx9QTdmtIuy3rM8gIhAI2LMke9OHf0BL5X9jFwthKVD38yhmhky2pCaPxdOoHB","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQDhOHgA04WPhqothHJwAETlqvM1pLkeGmcj+GaoBbEHrwIgYR+O+wNOp4ygxidHDQC7dolKgP/IOq3M8ehQRgSOeJQ=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.148","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"9a0f51ac8c2a36bf898655aec9bc3abff8bab721","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.148","@hydranium/langium":"1.0.0-next.148","@hydranium/protocol":"1.0.0-next.148","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.148"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.148","@hydranium/langium":"1.0.0-next.148","@hydranium/protocol":"1.0.0-next.148","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.148"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.148_1790637507955_0.6548188837800382","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.155":{"name":"@hydranium/cli","version":"1.0.0-next.155","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.155","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"a398f8f3c49d1e85f04971b7a8d86fa3944c0518","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.155.tgz","fileCount":277,"integrity":"sha512-jBB7s01nuLoSahmq9IiNVt4qtnY+6SFvh6MyKZj+tnLvdMcDt71tI98Fn87ID/1uqYFfo9JFyI3769+TcvBkFg==","signatures":[{"sig":"MEUCIBWRGhDNq/lOlnX9ya8VL6rmx7g2N3mh4c+A62313NLCAiEAlDlUY25q92DDI+xAmMygNjBcIea9Xj9biiA8E9mfOUA=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQCpKabXgyUrTsr0Kg7IQ1g0kdXMWAJQIIf2gMb4inGQnwIhAJWd9Pq3A0SGo9Je2tWYnjUs/YQ8bmGuKGScIVleniqf","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.155","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"2cb4a686814289a2d90c73f977358bd4c43f39b3","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.155","@hydranium/langium":"1.0.0-next.155","@hydranium/protocol":"1.0.0-next.155","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.155"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.155","@hydranium/langium":"1.0.0-next.155","@hydranium/protocol":"1.0.0-next.155","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.155"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.155_1790638636323_0.8252561907874829","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.157":{"name":"@hydranium/cli","version":"1.0.0-next.157","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.157","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"ef52064322d3c7936bac25334f0a4b13ea04d2c3","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.157.tgz","fileCount":277,"integrity":"sha512-ByIM6MdDdXp7nm1Aa1PiYJGFet+9El46YDsQFSejzCuVd1VohcmrXvjKY5oa8Q5P73JhymaZvqI6RTY9amY2eQ==","signatures":[{"sig":"MEUCIQCAHUMtRQ3T5hhYgcc5qLkD6m8mAt51eSAY5TVIrni9MgIgLt10n/KecdH85UHugJ3IR9uehlkQ22BOGaUtxFUf/Gw=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDnb2SZjH6A+Ml5+lvr48weXGNaGPQRAU4ytp/dmZh7PgIhAK5+d56H2xZL7OZ009Udor0akOYtgNwcZ5bCt/nxfrFu","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.157","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"eae73ff47f93d344488d34b082f92732c93ad31c","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.157","@hydranium/langium":"1.0.0-next.157","@hydranium/protocol":"1.0.0-next.157","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.157"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.157","@hydranium/langium":"1.0.0-next.157","@hydranium/protocol":"1.0.0-next.157","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.157"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.157_1790639180585_0.16859964707411446","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.158":{"name":"@hydranium/cli","version":"1.0.0-next.158","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.158","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"87f6d664e711f297fb21900935711138afda1aee","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.158.tgz","fileCount":277,"integrity":"sha512-aGwXRr51dyWcqBcnB45XiAgqrqEmNA6d3oFuA+798iGKlLyRg13f2Aw7dn87oW/K+D5kNQrob1pPoptpJlgG8Q==","signatures":[{"sig":"MEQCIHMZScGtKIVDzbgisIef4lZbB4vX/y2nAa6DDkF8fwBDAiAbdOaNGL01L64nI57iiqa8JRHjDJr8S7pQnYpYpZfZvg==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIClFWzop025lM5O+TBJQ77Co8PCigOz2um6w9lcmYK2LAiBw0vMpDkmeQs2hy1317UuaipsIILNA1hK0gFzic1Tn7g==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.158","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"1ee20631bc2bc0164de8f4b0fec71bbf78b0a9c2","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.158","@hydranium/langium":"1.0.0-next.158","@hydranium/protocol":"1.0.0-next.158","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.158"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.158","@hydranium/langium":"1.0.0-next.158","@hydranium/protocol":"1.0.0-next.158","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.158"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.158_1790757968475_0.8573126345348918","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.160":{"name":"@hydranium/cli","version":"1.0.0-next.160","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.160","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"40a0a37a22b9581333d892a2dc655d144cbec432","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.160.tgz","fileCount":277,"integrity":"sha512-BT/ZpE1vSKLmG6jhEC1n4AYDSIuMIlE+zd3QkFw6K7EitPLsLhOuC++fhw12hckLKov6tJXL5TokbMBp2carmw==","signatures":[{"sig":"MEUCIQDjUIvqYuAtcPoai9Y3P2F6sL9HXctmn26P/SQKNAHGyAIgALxCVHpNinYUWKmkGFa/D2ZQzlkQam2V0S8NfDfH77g=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDQ55Cq6yf83NUtVsBW522H3j44rTm9OOYktoF7+xLX3AIhAPFAmZcR0FpNAjDPTWJrHu1UeSDnhP1o8k+I2YpSTX6y","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.160","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"6cd23686acadcaf2dbb4ea757efb4ce32bacf77d","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.160","@hydranium/langium":"1.0.0-next.160","@hydranium/protocol":"1.0.0-next.160","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.160"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.160","@hydranium/langium":"1.0.0-next.160","@hydranium/protocol":"1.0.0-next.160","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.160"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.160_1790762377906_0.7708869326833077","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.168":{"name":"@hydranium/cli","version":"1.0.0-next.168","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.168","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"91f415037780c5690d302d8cc252424597b8bd32","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.168.tgz","fileCount":277,"integrity":"sha512-F56fc7HVGWcsqXRsF20uez8QWo8CXbDpvm/jyHCvODXkbz9ZOdD7Q1mAmw3gXC2LZFaU7O5E18MhIuQq5VmPxw==","signatures":[{"sig":"MEUCIAMWQaI+gBZtPwL2O6JXiA/JK4RqnyHuzoB6depg42AKAiEA2KwEjzzM7J1OOFzbA25eU2Cz8bjJwSOs6yaNOa5nufc=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQCTJ7IW3L2HR99n/XPkDdIgW7QF+QAx3mB3AWq2SOmUSQIgGv87Q04NWuMtRj6GL0fQy1gPXAUnfaluSZC0eILM3/Q=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.168","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"30b7b26e0bb67f2a7b372b5a62e83d45905d8663","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.168","@hydranium/langium":"1.0.0-next.168","@hydranium/protocol":"1.0.0-next.168","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.168"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.168","@hydranium/langium":"1.0.0-next.168","@hydranium/protocol":"1.0.0-next.168","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.168"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.168_1790777149372_0.5635971693217068","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.169":{"name":"@hydranium/cli","version":"1.0.0-next.169","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.169","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"83515b04a79984d69aeb0071bf3c235b0b41d432","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.169.tgz","fileCount":277,"integrity":"sha512-qTJvePpgmDseUPTQBaJZjHeBjtt8pmzWmkU+OfoODbJi8WnHlSHQv8YtxI0eptn4LWrKLrR4E4XoT6RugKzsGw==","signatures":[{"sig":"MEUCIQDwpzXk1wRRb+6wNG5Pdyx6/UnzkglpLNFNgQILjsbkwQIgfU4eFSBlHGuXTVKRRa4+owHLtWTL7/EWUALO3XbQ2IE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQD69f/sfX9EzoHKavq0tEiKaDnVL24qavy7iZv2Yzs1bAIgQgXpLglfYvmAVcxTUqKrWxBO+lzRa32G3UlRQxh2bBE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.169","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0a17cbf5e6bf32df0827e51ffbd602b4e722bf2c","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.169","@hydranium/langium":"1.0.0-next.169","@hydranium/protocol":"1.0.0-next.169","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.169"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.169","@hydranium/langium":"1.0.0-next.169","@hydranium/protocol":"1.0.0-next.169","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.169"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.169_1790783225418_0.8531429962798993","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.173":{"name":"@hydranium/cli","version":"1.0.0-next.173","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.173","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"005ac4c325a3083bfca7750b42fd87253fdd4a91","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.173.tgz","fileCount":277,"integrity":"sha512-J+J9itnjj69r00EH8cKhLeEx4Ib6+CADeNNl3xpZ8RV7zruV4HPpU6lwRAppBAMUmm4e5fPKUClwOAc4gcpPww==","signatures":[{"sig":"MEUCIQDgHVnHF5ObaG0j2WLrShUqDF/hae24YO9Lngv3JsuCLwIgaLSNZXb3o3ZmchA+ip/5S6sWqIFv8WPKc3/pydMmHaQ=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQD7JBTCNBpL0GIKIsbjPht8+YaRmGL4m349+SRCTG1W7QIhAOgeonUFWBD+hHeJGJBQjwHJ5ysJABFeBsFcw3IZHpUR","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.173","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"5bc225d4a40a2de4e9b175721db25ddb7e48c348","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.173","@hydranium/langium":"1.0.0-next.173","@hydranium/protocol":"1.0.0-next.173","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.173"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.173","@hydranium/langium":"1.0.0-next.173","@hydranium/protocol":"1.0.0-next.173","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.173"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.173_1790860426628_0.6287362173842779","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.174":{"name":"@hydranium/cli","version":"1.0.0-next.174","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.174","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"6dbfc8ff58c115115080d0db503c3416e4d57531","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.174.tgz","fileCount":277,"integrity":"sha512-1OVW6bGBmolk8s889mQg9iAfYSSPfikFFZwpRhqgEGKZ58lHAV58wcCxwm2DoWUWNH4YHZwjRJaM6+X4xVa0aQ==","signatures":[{"sig":"MEUCIAcq5efFZ/g65+bRQWLGQSczgBYdt5VUf1ls3QOTlN3aAiEA6Ha1rxf0GD8AX/9YYJOrdkD8JnV6CvoSmF4gXWbQ3CE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDNm7BwzlJK0s9/zMEVd0gE79X5yspEhtscV374PifMOwIhALzU2s4wP+Nj0UALH6GmwkyT09CR0/bjlGAyA6MNlWiF","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.174","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"58cc70efba83953130a58afc689770123cd9a73f","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.174","@hydranium/langium":"1.0.0-next.174","@hydranium/protocol":"1.0.0-next.174","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.174"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.174","@hydranium/langium":"1.0.0-next.174","@hydranium/protocol":"1.0.0-next.174","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.174"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.174_1790926738546_0.5084182556990942","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.175":{"name":"@hydranium/cli","version":"1.0.0-next.175","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.175","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"c6abb329211ed07396d8df54f37f6ea223a9122b","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.175.tgz","fileCount":277,"integrity":"sha512-qzSdfOpyKRf0NvvLQPjmspApb3ZhJwwfQ+xMBhLteNxck6Ey2y/tsnaowZai3FqSJrtfQeG/x7SyIBZk6dFuPQ==","signatures":[{"sig":"MEYCIQDcunC0a4TRNSGJMhPZV5QzikaaYSo2Kkn4KgmV4NO4SAIhAOuDG2kIBB2agsq67ItFL1JRs1PjI1QycfqtA+BkiP6n","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIEQuQA1p+H6k55heQqI9HDEUuguQ9Cb3wo8siLvpm4tKAiA5Ys6uLX3DQ63vAZ9E5XfgohQ8lGysdf2ZoQ5Z+TqmhQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.175","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1228213},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"55d99da61a0fbe06d1225d170854d5d7ed7beb4c","scripts":{"lint":"eslint src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.175","@hydranium/langium":"1.0.0-next.175","@hydranium/protocol":"1.0.0-next.175","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.175"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.175","@hydranium/langium":"1.0.0-next.175","@hydranium/protocol":"1.0.0-next.175","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.175"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.175_1790927371806_0.6467227965152349","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.176":{"name":"@hydranium/cli","version":"1.0.0-next.176","keywords":["hydranium","langium","language-server","lsp","cli","codegen"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.176","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"1fc7a0b43b9fe7a689690f405cfeffbd2601c1a4","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.176.tgz","fileCount":277,"integrity":"sha512-ElT/ZSIBXDOgNBjezBrDL9NQnI9vUGBA3X1XawFprYx++XVqXLumvtdWBpCXlSth+AA+qnhEMJG02ncc259fCA==","signatures":[{"sig":"MEYCIQDDMGnJjYyJ3y4owADjv/ZyGSWIgQ3ZzJgCfb7SPRWcqwIhAJfR4u1JKKFAo3z6QhniReDfY5WdKTTNB9feF+w2g6Bc","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDEFktGZRjuE9PDQ2EvCnk/SsGIWEd0aYGFrvbi1Fs6bQIhAJuXJSWXfor27eO0K0+ySPOdLKFrrA19DeDj0n45I5Sv","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.176","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1231385},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"f2701eb5d00f38595d2099980346074d70ce4ee8","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.176","@hydranium/langium":"1.0.0-next.176","@hydranium/protocol":"1.0.0-next.176","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.176"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.176","@hydranium/langium":"1.0.0-next.176","@hydranium/protocol":"1.0.0-next.176","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.176"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.176_1790935391635_0.05040082932054757","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.177":{"name":"@hydranium/cli","version":"1.0.0-next.177","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.177","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"0a1fef34fbe6652df8edfa466d458837ab8b2c83","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.177.tgz","fileCount":277,"integrity":"sha512-bb6Z9G4wcY8MgvB7G5myWmJg9w3BNinYTTxfIMwARrAk5xrrBBnlz0Zz09SplCTDb5LFLpjgonV7lWy4Rd0jOQ==","signatures":[{"sig":"MEYCIQD0NE5u5BIF73ugq3mkH3c6sDZHBDV+9tg0rpNOKIdbHAIhAN2cHu5zIojLia38UeuoW3nGwUteubeFTqjxln3ewvZl","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEQCIGimK9tUDHiqy0T1N7p8tfrBmdxTkok35m+0rV3984gOAiBgmgMK4Vv09nU5CStuKJbB1x+3aU6w8fP9cWKvrEtmag==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.177","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1232129},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0bd2ddad64f34cf251c80077f0755b69eae738b9","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^5.8.0","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.177","@hydranium/langium":"1.0.0-next.177","@hydranium/protocol":"1.0.0-next.177","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.177"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.177","@hydranium/langium":"1.0.0-next.177","@hydranium/protocol":"1.0.0-next.177","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.177"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.177_1790940535795_0.8562699564772556","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.179":{"name":"@hydranium/cli","version":"1.0.0-next.179","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.179","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"lib/cli.js"},"dist":{"shasum":"85f4602787bb8c35650a1042e4e3f2191fb296e7","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.179.tgz","fileCount":277,"integrity":"sha512-BZW0uqCPeFgjP4jVhCw/GIFT8lzrmD3QJPgXdXBZCAcQdehUzH8fWR93uHVmsfsTfE/mFNlJiR7yXXVXWzdKyg==","signatures":[{"sig":"MEYCIQDvaQ8nGCmd9ZiekSV3i9TNV8mKPHL4h+5tNkjY4VNybwIhAPFu55QYGJmbesfVy2Ka511WbtUmvVhjAk38PI96QyC3","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEYCIQDTH9JGSBTdPK/aiddPDm0CbxZFMetXXkracwlFHA70uwIhAIIo7tl6zj2rx+xpmm47JW9acWw4IbYXXAu/8FcO/Jsy","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.179","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1232238},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","//build":"The chmod is load-bearing, not cruft. npm sets a bin's executable bit through bin-links' fixBin, but ONLY when it first creates the link — and `tsc` never sets it, so after `npm run clean` (which deletes lib/) a rebuild leaves lib/cli.js at 0644 and the node_modules/.bin/hydranium-cli symlink resolves to a non-executable target. Every example's `generate` step then dies with `sh: hydranium-cli: Permission denied`, surfacing as an opaque npm error code 127 during `turbo run build`. npm rebuild, npm rebuild @hydranium/cli AND a full npm install all fail to restore it, because npm will not revisit an existing workspace symlink; only a from-scratch `rm -rf node_modules` install does. Written as `node -e` rather than `chmod +x` so it stays portable — on Windows npm generates .cmd/.ps1 shims where the bit is irrelevant and chmodSync is harmless. The example packages' bins need no such step: their tests spawn them via process.execPath, never through the shim.","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"d98696eba7798a8392b601d15a66884764e59d9d","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b && node -e \"require('node:fs').chmodSync('lib/cli.js',0o755)\"","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^7.0.2","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.179","@hydranium/langium":"1.0.0-next.179","@hydranium/protocol":"1.0.0-next.179","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.179"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.179","@hydranium/langium":"1.0.0-next.179","@hydranium/protocol":"1.0.0-next.179","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.179"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.179_1790943444439_0.3517136472981426","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.180":{"name":"@hydranium/cli","version":"1.0.0-next.180","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.180","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"bin/hydranium-cli.js"},"dist":{"shasum":"6498f2e560bcb645836a41190edc7a3749d0e360","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.180.tgz","fileCount":278,"integrity":"sha512-xCE3buMJhi/ewJgHW0z1iBuFSrIgZFiTGV4g+KFO8yQ3R27MR6y8sCm7gF2mwK8uTREA6nHpMJcxGyxBmRa7qQ==","signatures":[{"sig":"MEUCIBU1WIkA0O2FQvSiz5nuhb7iqpqt9IVBVMBAL+ef5dZxAiEAi4qqFHgSy6pO/B7LFAqZW0Eichys2gF8E9wPzR+/jEE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQCzWNVaoAsggBZv5uqqJkNTNPy0+d+oJ50FcmPOuENa/AIgcak/eZklkg8Bdlsj0jb5xIvc+QMZTYRT2iheugtYwdE=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.180","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1231825},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"c9ca6f89b51f3cc93e1316bda7710f30c130187f","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^7.0.2","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.180","@hydranium/langium":"1.0.0-next.180","@hydranium/protocol":"1.0.0-next.180","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.180"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.180","@hydranium/langium":"1.0.0-next.180","@hydranium/protocol":"1.0.0-next.180","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.180"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.180_1790945014422_0.07657087206470403","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.181":{"name":"@hydranium/cli","version":"1.0.0-next.181","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.181","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"bin/hydranium-cli.js"},"dist":{"shasum":"e31ecb5866e9031fdb1b4eaa0dae9a702885f52d","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.181.tgz","fileCount":278,"integrity":"sha512-GJjP4x5gL9ubLAaswUlDsu1QmpCuhu21wJroTB+RcJOO3bE8LUhASUSCpbJRN+2W8+mEuL/6IHtHdnMgoImsxA==","signatures":[{"sig":"MEYCIQC3b8sBEBVD+98frTVVSNgCFvOlB4igP1YDAyqI/flMVwIhAOLbk9uSCSWe5Y/FT4tYUiNKZTUpTbYZ5m5Gt1yROQfV","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIGmBx5Devh0ZCQAOB4Jkkk4OQxbwBZZp1aU4Ag+aDtcEAiEA/oluQoCG+2/QTEZfS9dI1ixwgWFbI1Y215UV3148d2Q=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.181","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1231825},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"2c50797f9ce8e785cd1f2269e6273bb4f6425662","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.13.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^7.0.2","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.181","@hydranium/langium":"1.0.0-next.181","@hydranium/protocol":"1.0.0-next.181","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.181"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.181","@hydranium/langium":"1.0.0-next.181","@hydranium/protocol":"1.0.0-next.181","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.181"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.181_1790945522665_0.28044119220240527","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.183":{"name":"@hydranium/cli","version":"1.0.0-next.183","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"author":{"name":"Hydranium Team"},"license":"MIT","_id":"@hydranium/cli@1.0.0-next.183","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"bin":{"hydranium-cli":"bin/hydranium-cli.js"},"dist":{"shasum":"6a997222f3ae0df8cf8b00d37ad3210fabb28848","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.183.tgz","fileCount":278,"integrity":"sha512-Dy9vhzf5eNL2eXfmThPdPmF13OfTlPfGEnvVjeOrkx4z7vw06NLMoPL/i2cWpQsoFKp6Nu99sCVhgy1SpdK0PQ==","signatures":[{"sig":"MEQCIFIPwbM5FQn7rJCmpzgslj+eMSBvcAz9iTkIT+GHcZ2oAiArTRXwXrl2P7SWntgQHuARgfJHmgpPCHtrZ1xfQc8Afw==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIQD/h/Sk9TAY4LkgaIFr2vQeGzWQD5IPIY7eYBRuJxm1gwIgfF7sBWlb2b8QDVEj+ayXcA6NQTzdl5jOkRpHP6E3xpM=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.183","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1231825},"main":"lib/index.js","type":"module","types":"lib/index.d.ts","engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"fe055eb63801c1e2f1943b55ff7821f2774b9ff7","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.18.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^7.0.2","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.183","@hydranium/langium":"1.0.0-next.183","@hydranium/protocol":"1.0.0-next.183","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.183"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.183","@hydranium/langium":"1.0.0-next.183","@hydranium/protocol":"1.0.0-next.183","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.183"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"tmp":"tmp/cli_1.0.0-next.183_1790947711181_0.10179135157992025","host":"s3://npm-registry-packages-npm-production"}},"1.0.0-next.185":{"_id":"@hydranium/cli@1.0.0-next.185","bin":{"hydranium-cli":"bin/hydranium-cli.js"},"bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"dist":{"shasum":"8f3017d09232c05a22ba1a3fabd2b765fb85e7fc","tarball":"https://registry.npmjs.org/@hydranium/cli/-/cli-1.0.0-next.185.tgz","fileCount":278,"integrity":"sha512-805R9b6xuo/WNgUsIIoewm5Zpm20Gr9dO5zfaFIOGx3p8DBW7me7HRsfap9Z1PHg7NEwz3RYPhXiyztYCakoXw==","signatures":[{"sig":"MEQCIC+G6SkDEIVJe7nqTQdPc53BZ1S0WgoSljcqwgofOxciAiAr23ZtuRXskQ3R6cMM7Ru+myZd5EAHKfdgRU3hZTCFPQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEUCICHPnKYcgeRqHhvPcrXu5xsZzx301lwAY9Z3MYvemfaZAiEA/bQo0MQacK06n4BXjU/uXB4HfM+kJzkL461dY7bM9wM="}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@hydranium%2fcli@1.0.0-next.185","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":1231825},"main":"lib/index.js","name":"@hydranium/cli","type":"module","types":"lib/index.d.ts","author":{"name":"Hydranium Team"},"engines":{"node":">=22.13"},"exports":{".":{"types":"./lib/index.d.ts","default":"./lib/index.js"},"./lib/cli.js":{"types":"./lib/cli.d.ts","default":"./lib/cli.js"}},"gitHead":"0c1f5de214bdd827a96cf271263260f8fb9759d3","license":"MIT","scripts":{"lint":"oxlint --format stylish --config ../../oxlint.config.cjs src test --max-warnings 0","test":"npm run typecheck:test && vitest run","build":"tsc -b","clean":"rimraf lib tsconfig.tsbuildinfo","watch":"tsc -b -w --preserveWatchOutput","prepack":"node -e \"const m=require('./package.json'),fs=require('node:fs');const missing=[m.main,...Object.values(m.bin||{})].filter(entry=>entry&&!fs.existsSync(entry));if(missing.length){console.error('prepack '+m.name+': not built ('+missing.join(', ')+' missing). Run the build before packing: a files entry that matches nothing is skipped silently, so the tarball would ship src only.');process.exit(1);}\"","typecheck:test":"tsc --noEmit -p tsconfig.test.json"},"version":"1.0.0-next.185","//memlab":"@memlab/core and @memlab/heap-analysis are OPTIONAL PEER dependencies, not optionalDependencies, and the distinction is the whole point: npm installs optionalDependencies BY DEFAULT, both memlab packages pin puppeteer exactly, and puppeteer's postinstall downloads a Chrome binary — so every adopter of this CLI paid ~86 MB and a browser download for the one subcommand almost none of them run, and the download can fail and be walked past as a warning. An optional peer is not auto-installed, so `analyze-heap` documents `npm install @memlab/core @memlab/heap-analysis` as the opt-in and every other subcommand is unaffected. Taken pre-publish deliberately: after publish the install shape is what adopters already have.","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"4e8d41da-1e99-4dd6-9e7a-fdbdb1086cb8"}},"homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"//exports":"Two keys, and the SHORT list is the point: `files` ships the whole compiled tree, so without a map every `lib/commands/*.js`, every internal helper and `lib/testing/echo-server.js` is deep-importable the moment this publishes, and semver then applies to all of it. `.` is the library barrel (the data-server subcommands an adopter calls as functions). `./lib/cli.js` is the BINARY ARTEFACT, and it is declared because a consumer that spawns the CLI resolves it BY SPECIFIER — `createRequire(import.meta.url).resolve('@hydranium/cli/lib/cli.js')` — to get the path npx would run; `bin` gives a shim on PATH, not a path, so dropping this key breaks that resolution and the failure surfaces as \"hydranium-cli is not built\", naming the wrong cause. It is declared in the `/lib/` spelling ONLY: that spelling already resolves under both of this repo's module resolvers, so the twin rule (which exists so a BARE subpath is reachable from node10) has nothing to add here and a bare twin would only be a second name for one artefact. `heap-analysis/` needs no key even though `files` ships it — `analyze-heap` reaches the analyzer through a `new URL(..., import.meta.url)` file URL, which `exports` does not gate, and the package's own tests reach it relatively. `./testing` is deliberately absent: `echo-server` is a spawnable stdio fixture, not a reusable export.","//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.","repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"_npmVersion":"11.15.0","description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","directories":{},"maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"sideEffects":["./lib/cli.js","./lib/commands/*-driver.js","./lib/testing/echo-server.js"],"_nodeVersion":"22.18.0","dependencies":{"ts-morph":"^25.0.0","commander":"^14.0.3","@clack/prompts":"~1.7.0"},"//sideEffects":"The listed modules RUN on load rather than exporting anything: `cli.js` is the `bin`, each `*-driver.js` is spawned as its own process and calls `main(process.argv)` at top level, and `echo-server.js` starts a server. Their whole purpose is the effect, so a bundler must never treat them as prunable. Everything else here is library code with no module-level state beyond `new URL(..., import.meta.url)` constants.","publishConfig":{"access":"public"},"_hasShrinkwrap":false,"devDependencies":{"rimraf":"^5.0.0","typescript":"^7.0.2","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.185","@hydranium/langium":"1.0.0-next.185","@hydranium/protocol":"1.0.0-next.185","vscode-languageserver":"~10.0.1","@hydranium/data-server":"1.0.0-next.185"},"peerDependencies":{"@memlab/core":"^2.0.3","vscode-jsonrpc":"9.0.1","@hydranium/core":"1.0.0-next.185","@hydranium/langium":"1.0.0-next.185","@hydranium/protocol":"1.0.0-next.185","@memlab/heap-analysis":"^2.0.3","@hydranium/data-server":"1.0.0-next.185"},"//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`. It does NOT prevent a NESTED copy — `@eclipse-glsp/*` carries its own exact `vscode-jsonrpc@8.2.0` dependency and root `overrides` do not ship — so a consumer of the GLSP head must pin the chain in its own manifest, and docs/adopting/requirements.md carries the block to paste.","peerDependenciesMeta":{"@memlab/core":{"optional":true},"@memlab/heap-analysis":{"optional":true}},"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/cli_1.0.0-next.185_1790957417330_0.1722114500037346"}}},"time":{"created":"2026-09-08T23:04:08.703Z","modified":"2026-10-02T16:10:17.830Z","1.0.0-next.4":"2026-09-08T23:04:09.046Z","1.0.0-next.5":"2026-09-08T23:45:20.660Z","1.0.0-next.6":"2026-09-09T09:16:00.321Z","1.0.0-next.7":"2026-09-09T11:31:33.983Z","1.0.0-next.8":"2026-09-09T11:39:42.538Z","1.0.0-next.9":"2026-09-09T12:47:48.570Z","1.0.0-next.10":"2026-09-09T14:06:40.782Z","1.0.0-next.11":"2026-09-09T14:17:46.908Z","1.0.0-next.12":"2026-09-09T15:59:00.682Z","1.0.0-next.13":"2026-09-10T08:09:21.524Z","1.0.0-next.14":"2026-09-10T09:22:47.845Z","1.0.0-next.15":"2026-09-10T09:31:49.918Z","1.0.0-next.16":"2026-09-10T09:49:56.511Z","1.0.0-next.17":"2026-09-10T10:45:29.540Z","1.0.0-next.18":"2026-09-10T11:03:52.999Z","1.0.0-next.19":"2026-09-10T13:28:57.363Z","1.0.0-next.22":"2026-09-10T20:25:40.861Z","1.0.0-next.23":"2026-09-10T20:45:57.789Z","1.0.0-next.24":"2026-09-10T21:00:15.148Z","1.0.0-next.25":"2026-09-10T21:18:11.213Z","1.0.0-next.27":"2026-09-10T21:39:37.051Z","1.0.0-next.28":"2026-09-10T21:54:26.275Z","1.0.0-next.29":"2026-09-10T22:38:05.944Z","1.0.0-next.30":"2026-09-10T22:52:43.553Z","1.0.0-next.31":"2026-09-10T23:09:06.963Z","1.0.0-next.32":"2026-09-10T23:25:05.291Z","1.0.0-next.33":"2026-09-10T23:50:56.217Z","1.0.0-next.34":"2026-09-10T23:58:06.022Z","1.0.0-next.35":"2026-09-11T07:12:49.455Z","1.0.0-next.36":"2026-09-11T07:24:25.262Z","1.0.0-next.37":"2026-09-11T07:31:38.155Z","1.0.0-next.38":"2026-09-11T07:42:23.401Z","1.0.0-next.39":"2026-09-11T07:59:12.932Z","1.0.0-next.40":"2026-09-11T08:49:10.742Z","1.0.0-next.42":"2026-09-11T10:43:32.005Z","1.0.0-next.44":"2026-09-11T11:57:18.103Z","1.0.0-next.45":"2026-09-11T12:33:03.582Z","1.0.0-next.46":"2026-09-11T13:03:30.284Z","1.0.0-next.49":"2026-09-15T11:56:10.698Z","1.0.0-next.50":"2026-09-15T12:33:59.667Z","1.0.0-next.51":"2026-09-15T12:55:01.620Z","1.0.0-next.52":"2026-09-15T14:54:07.842Z","1.0.0-next.55":"2026-09-16T12:54:12.798Z","1.0.0-next.57":"2026-09-16T15:27:02.514Z","1.0.0-next.58":"2026-09-16T15:35:05.071Z","1.0.0-next.60":"2026-09-17T08:47:04.709Z","1.0.0-next.61":"2026-09-17T11:05:11.022Z","1.0.0-next.62":"2026-09-17T13:12:43.672Z","1.0.0-next.63":"2026-09-17T13:20:17.948Z","1.0.0-next.66":"2026-09-17T21:27:37.473Z","1.0.0-next.67":"2026-09-18T07:52:04.419Z","1.0.0-next.70":"2026-09-18T11:03:14.225Z","1.0.0-next.71":"2026-09-18T11:16:12.219Z","1.0.0-next.72":"2026-09-18T12:41:56.138Z","1.0.0-next.74":"2026-09-18T14:21:09.146Z","1.0.0-next.75":"2026-09-18T15:09:33.693Z","1.0.0-next.76":"2026-09-18T20:57:08.815Z","1.0.0-next.77":"2026-09-18T21:56:28.106Z","1.0.0-next.79":"2026-09-20T15:02:30.237Z","1.0.0-next.85":"2026-09-20T21:23:41.017Z","1.0.0-next.86":"2026-09-21T07:13:53.417Z","1.0.0-next.88":"2026-09-21T08:37:17.228Z","1.0.0-next.90":"2026-09-21T10:22:31.921Z","1.0.0-next.91":"2026-09-21T10:34:31.249Z","1.0.0-next.92":"2026-09-21T12:17:22.674Z","1.0.0-next.93":"2026-09-21T13:13:14.927Z","1.0.0-next.94":"2026-09-21T13:34:45.117Z","1.0.0-next.95":"2026-09-21T14:35:18.952Z","1.0.0-next.96":"2026-09-23T17:58:34.825Z","1.0.0-next.97":"2026-09-23T18:03:15.033Z","1.0.0-next.98":"2026-09-23T18:14:00.706Z","1.0.0-next.103":"2026-09-23T18:36:44.636Z","1.0.0-next.104":"2026-09-23T18:45:46.090Z","1.0.0-next.105":"2026-09-23T18:56:29.212Z","1.0.0-next.106":"2026-09-23T19:45:24.175Z","1.0.0-next.107":"2026-09-23T20:28:37.407Z","1.0.0-next.109":"2026-09-23T22:59:50.263Z","1.0.0-next.111":"2026-09-24T13:28:52.404Z","1.0.0-next.112":"2026-09-24T14:35:46.288Z","1.0.0-next.113":"2026-09-24T15:38:02.286Z","1.0.0-next.114":"2026-09-24T16:44:13.787Z","1.0.0-next.115":"2026-09-24T21:47:25.442Z","1.0.0-next.117":"2026-09-28T21:44:19.213Z","1.0.0-next.123":"2026-09-28T22:09:36.316Z","1.0.0-next.127":"2026-09-28T22:34:34.906Z","1.0.0-next.132":"2026-09-28T22:47:13.739Z","1.0.0-next.135":"2026-09-28T22:54:53.641Z","1.0.0-next.140":"2026-09-28T23:03:45.016Z","1.0.0-next.148":"2026-09-28T23:18:28.068Z","1.0.0-next.155":"2026-09-28T23:37:16.419Z","1.0.0-next.157":"2026-09-28T23:46:20.682Z","1.0.0-next.158":"2026-09-30T08:46:08.590Z","1.0.0-next.160":"2026-09-30T09:59:37.996Z","1.0.0-next.168":"2026-09-30T14:05:49.485Z","1.0.0-next.169":"2026-09-30T15:47:05.540Z","1.0.0-next.173":"2026-10-01T13:13:46.756Z","1.0.0-next.174":"2026-10-02T07:38:58.687Z","1.0.0-next.175":"2026-10-02T07:49:31.924Z","1.0.0-next.176":"2026-10-02T10:03:11.745Z","1.0.0-next.177":"2026-10-02T11:28:55.947Z","1.0.0-next.179":"2026-10-02T12:17:24.577Z","1.0.0-next.180":"2026-10-02T12:43:34.524Z","1.0.0-next.181":"2026-10-02T12:52:02.786Z","1.0.0-next.183":"2026-10-02T13:28:31.260Z","1.0.0-next.185":"2026-10-02T16:10:17.444Z"},"bugs":{"url":"https://github.com/eclipse-emfcloud/hydranium/issues"},"author":{"name":"Hydranium Team"},"license":"MIT","homepage":"https://github.com/eclipse-emfcloud/hydranium/tree/main/packages/cli","keywords":["cli","codegen","hydranium","langium","language-server","lsp"],"repository":{"url":"git+https://github.com/eclipse-emfcloud/hydranium.git","type":"git","directory":"packages/cli"},"description":"Build-time codegen tools + data-server subcommands for the hydranium framework.","maintainers":[{"name":"mfleck","email":"mfleck@eclipsesource.com"}],"readme":"# `@hydranium/cli`\n\nThe headless tool surface of the [Hydranium](https://github.com/eclipse-emfcloud/hydranium)\nframework, published as the `hydranium-cli` binary.\n\nInstall it if you are building a Hydranium language. `init` scaffolds a complete project from one\ninvocation; the other twelve subcommands drive an already-built head from a shell or a CI step —\ngrammar introspection, headless validation, transfer-model codegen, memory measurement, and\noperations against a spawned data-server.\n\n## What it gives you\n\n- **`init`** — a buildable project (starter grammar, `create<Name>Services` DI wiring, an LSP +\n  data-server launch, `langium-config.json`, build scripts) from one command, or from a wizard that\n  echoes the flags it composed.\n- **CI gates that need no editor** — `validate` exits non-zero on a diagnostic; `lint-grammar`\n  checks that every concrete cross-reference target carries a name property and that each language\n  declares an entry rule.\n- **Grammar introspection** — `reflect` (type hierarchy, terminals, every cross-reference target;\n  Markdown or `--json`) and `model-docs` (a navigable Markdown model reference for your own docs).\n- **Codegen** — `generate-transfer-model` turns a Langium-generated AST into a serializable transfer\n  model, once or in `--watch`.\n- **Memory and profiling** — `measure-memory`, `ast-ground-truth`, and the memlab-based\n  `analyze-heap`.\n- **Data-server operations** — `projects`, `query`, `save` and `watch` spawn a data-server child and\n  speak its protocol, printing JSON / NDJSON a script can pipe.\n\n## Install\n\n> **Nothing in `@hydranium/*` is on npm yet**, so every `npx` line below\n> resolves to no package and fails with `E404`. Until the first release the CLI\n> is reachable only from a clone of this repository: run `npm run build`, then\n> substitute `node packages/cli/lib/cli.js` for the `npx …` prefix. Subcommands,\n> flags and output are the same either way.\n\n`init` needs no install at all:\n\n```bash\nnpx @hydranium/cli init ./my-lang --name MyLang\n```\n\nFor the subcommands you run repeatedly, add it to the project it inspects, or install it globally:\n\n```bash\nnpm install --save-dev @hydranium/cli\nnpm install --global @hydranium/cli\n```\n\nThe framework edges are **peer dependencies** — `@hydranium/core`, `@hydranium/data-server`,\n`@hydranium/langium`, `@hydranium/protocol` and `vscode-jsonrpc` — so the CLI runs the same physical\ncopies as the head it inspects (`init` itself needs none of them). The memlab packages\n`analyze-heap` loads are **optional peer dependencies**, so installing this package pulls no browser:\nrun `npm install @memlab/core @memlab/heap-analysis` (heavy, ~86 MB) before the first\n`analyze-heap`. Every other subcommand works without them.\n\n## Subcommands\n\n`hydranium-cli --help` lists them; `hydranium-cli <command> --help` prints one command's own flags.\n\nMost subcommands take `--services <module>`: an ESM module exporting a zero-arg\n`createServices(): { shared }` thunk — normally your build's `./lib/services.js`. The head wires its\nown filesystem inside, so the CLI boots it with no arguments.\n\n**Scaffolding**\n\n- `init <target-dir>` — scaffold a new language project. See the section below.\n\n**Grammar and workspace** (`--services <module>`)\n\n- `reflect` — dump the grammar/AST reflection: type hierarchy, per-language terminals and entry\n  rule, every cross-reference target. `--json`, `--out-file <file>`.\n- `lint-grammar` — check the grammar against framework conventions; non-zero exit on a violation.\n  `--name-property <p>` (repeatable), `--strict`, `--json`.\n- `model-docs` — emit a navigable Markdown model reference on stdout, or into `--out-file <file>`.\n- `validate <workspace>` — build a workspace headlessly and report its diagnostics; non-zero exit on\n  any error. `--strict` (also fail on warnings), `--json`, `--out-file <file>`.\n- `measure-memory <workspace>` — measure model-store memory in an `--expose-gc` child.\n  `--edits <N>`, `--edit-docs <N>`, `--churn-suffix <ext>`, `--settle <ms>`, `--snapshot`,\n  `--snapshot-path <p>`, `--profile <dims>`, `--session-out <dir>`, `--json`.\n- `ast-ground-truth <workspace>` — tally the live model's AST nodes by `$type`, the ground truth\n  `analyze-heap --validate` checks a snapshot against. `--out-file <file>`.\n\nAll six also take `--log-level <off|error|warn|info|debug|trace>`, which sets the threshold for the\nhead the subcommand boots — not for the CLI itself. It reaches the head through the child's\nenvironment, so a head that binds a logger of its own decides what the flag means to it.\n\nThe three `<workspace>` commands resolve that argument to an existing directory before they start —\na filesystem path or a `file:` URI — and exit 2 naming it when it reaches none. Without that a CI\nstep whose path has rotted builds nothing, reports whatever documents the head contributes\nindependently of the workspace, and exits 0; the count is a property of the head, so it can be\nplausibly non-zero and cannot be read as the tell.\n\n**Codegen**\n\n- `generate-transfer-model` — generate a transfer-model TypeScript file from a Langium AST.\n  `--ast-file`, `--augmentation-file` and `--out-file` are required, and may come from\n  `--config <path>` instead; `--langium-config <path>` derives `--ast-file` from that config's `out`\n  directory. `--watch` regenerates on change, and the output-naming flags (`--element-type-name`,\n  `--terminals-name`, `--terminals-source-name`, `--skip-type-alias`, `--skip-terminal`,\n  `--regen-command`) tune the emitted file.\n\n**Heap analysis**\n\n- `analyze-heap <snapshot>` — Langium-aware V8 heap-snapshot analysis. Its flags (`--out-file`,\n  `--json`, `--diff`, `--validate <gt.json>`, `--renderer`, and the drill-down tuning flags) are\n  declared alongside every other subcommand's, so an unrecognised one is rejected rather than\n  ignored.\n\n**Child-process heap ceiling** (`HYDRANIUM_CLI_MAX_OLD_SPACE_MB`)\n\nSubcommands that spawn a child — `analyze-heap`, `measure-memory`, `validate`, `lint-grammar`,\n`reflect`, `model-docs`, `ast-ground-truth` — give it `--max-old-space-size=8192` on a machine with\nno cgroup memory limit, and **no ceiling at all when there is one**. A ceiling above the limit lets\nV8 grow past it without collecting hard, so the kernel kills the container rather than the child\nreporting a heap error.\n\nUnder a limit, Node derives its own ceiling from that limit, which is a fraction of it — so a\nroomy container gives a child less than the same machine would unconstrained. Set\n`HYDRANIUM_CLI_MAX_OLD_SPACE_MB` to state a ceiling in MiB; it wins in a container too. `0` means\n\"let Node decide\". A value below 256, or one carrying a unit suffix, is reported and ignored rather\nthan passed on.\n\n**Data-server operations** (`--server \"<cmd> [args...]\"`)\n\nThese spawn a data-server child and talk to it over its protocol. All four also take `--cwd <dir>`\nand `--log-level <off|error|warn|info|debug|trace>`.\n\n`--server` has to name an entry that puts the **data** protocol on stdio, which for a scaffolded\nproject is `lib/data-server-main.js` — `init` emits it, and the `<project-id>-data-server` bin key\npoints at it. `lib/main.js` is the editor entry: stdio there carries LSP and the data head is a\nsocket whose port is published over the LSP connection, so pointing `--server` at it answers\n`Unhandled method data-server/getProjects` (or, without `--stdio`, exits on \"Connection input stream\nis not set\"). Pass the workspace as the entry's own argument rather than through `--cwd`: `--cwd`\nre-roots the child, so a relative entry path would resolve against the workspace — the parser\nrefuses that combination by name rather than letting the child fail on a bare module-not-found.\nAn absolute entry path works with `--cwd`.\n\n```bash\nhydranium-cli projects --server \"node ./lib/data-server-main.js ./models\"\n```\n\n- `projects` — list the projects the server exposes, one JSON envelope per line.\n- `query --uri <uri>` — print that document's envelope as a single JSON line.\n- `save --uri <uri> --content <text|@file>` — update and persist the document; an `@`-prefixed value\n  reads the content from a file. `--client-id <id>`. This is the only writing subcommand, and it\n  spawns a data server of its own: a workspace has a **single writer**, so pointing it at one an\n  editor already has open is two writers and the later write wins. Neither process will see a\n  half-written file, but nothing serialises them either, so a lost write is the documented\n  outcome rather than a defect — the guarantee, its one exception and what it does not cover are\n  in [Status: one process writes a workspace](../../docs/adopting/status.md#one-process-writes-a-workspace).\n- `watch --uri <uri>` — subscribe to document updates and print events as NDJSON until Ctrl-C.\n  `--client-id <id>`.\n\n## `init` in detail\n\n`init` writes a project you can build immediately, and it writes **only inside the target\ndirectory** — it refuses a non-empty directory without `--force`, and it never edits a surrounding\nmanifest (a root `workspaces` entry is printed, not added). It also does **not** run `npm install`\nor `langium generate`; both are printed as next steps.\n\nProject options are position-free:\n\n- `<target-dir>` and `--name <Name>` are required. `--name` is the PascalCase **project** name and\n  drives the shared generated symbols (`<Name>AstReflection`, `<Name>GeneratedSharedModule`).\n- `--heads <list>` picks the protocol heads from `lsp`, `data`, `glsp`; default `lsp,data`. `lsp` is\n  mandatory — it owns the workspace, the build pipeline and the shared tier the others read through.\n- `--monorepo` scaffolds a member of the surrounding npm workspace, `--scope <@scope>` sets the npm\n  scope, `--public` drops the emitted `\"private\": true`, `--force` allows a non-empty directory.\n\nThe emitted manifest carries `files` (`lib`, `src`, `syntaxes`), a derived `description` and\n`keywords`, and an empty `author` for you to fill. It is `\"private\": true` unless you pass\n`--public`, because it also declares `\"license\": \"UNLICENSED\"` — a scaffold cannot pick a licence for\nyour project, and a package that grants no rights has no business being publishable to a public\nregistry. Choose a licence, then pass `--public`. The wizard asks this on every run rather than\nletting a default settle it. `files` is not cosmetic: without it npm falls back\nto the `.gitignore` the scaffold also writes, which ignores `lib/` — so a publish would ship `main`\nand omit the `bin` targets beside it, and succeed. There is deliberately no `repository`: a scaffold\ncannot know yours, and tooling follows that field rather than merely displaying it.\n\nThere is one `bin` key per executable entry — `<project-id>` for `src/main.ts`, plus\n`<project-id>-data-server` for `src/data-server-main.ts` when `data` is in `--heads`. Both sources\nbegin with a `#!` line, because npm sets the exec bit on a linked target without adding one: a\nfirst line that is anything else is handed to the shell.\n\nGrammar options are **repeatable and order-scoped**: each applies to the `--grammar` it follows.\n\n- `--grammar <Name>` — the PascalCase grammar name; pass it once per grammar. Defaults to `--name`.\n- `--extensions <list>` — comma-separated file extensions for that grammar, leading dot optional;\n  accumulates. Defaults to the kebab-cased grammar name.\n- `--language-id <id>` — override that grammar's derived routing key.\n- `--diagram` — scaffold a GLSP diagram for that grammar; requires `glsp` in `--heads`.\n\nLeave `--name` off on an interactive terminal and `init` prompts instead, then echoes the command it\ncomposed before running it — so the wizard is a way to reach an `init` command line, not an\nalternative to one. Without a TTY a missing `--name` stays an error, so CI never hangs.\n\n```bash\n# Scaffold, install, build\nnpx @hydranium/cli init ./my-lang --name MyLang\ncd my-lang\nnpm install\nnpm run build                # langium generate + tsc, into lib/\nnpm test                     # the scaffolded DI-composition test\n\n# The editor entry: LSP on stdio, every other head on a published socket\nnode lib/main.js --stdio\n\n# The data head alone, on stdio — the entry the four --server subcommands spawn\nhydranium-cli projects --server \"node ./lib/data-server-main.js ./models\"\n\n# Drive the rest of the CLI against the built factory\nnpx hydranium-cli reflect      --services ./lib/services.js\nnpx hydranium-cli lint-grammar --services ./lib/services.js\nnpx hydranium-cli validate     --services ./lib/services.js ./models\nnpx hydranium-cli model-docs   --services ./lib/services.js --out-file model-reference.md\n\n# Several grammars, three heads, one of them with a diagram\nnpx @hydranium/cli init ./order-flow --name OrderFlow --heads lsp,data,glsp \\\n   --grammar Domain --grammar Process --diagram \\\n   --grammar Layout --extensions diagram\n```\n\nThe scaffold wires only the framework defaults. The seams a real language customizes are walked\nbeside those defaults in\n[`docs/concepts/framework-vs-adopter.md`](../../docs/concepts/framework-vs-adopter.md).\n\n## Entry points\n\nThis package declares a two-key `exports` map — the root barrel and the CLI\nbinary — plus a `main` and a `bin`. The binary key is spelled `./lib/cli.js` and\ncarries no bare alias: the pairing rule that gives every subpath a `./lib/` twin\nruns one way only, and a key already spelled that way resolves under both\nresolvers as it stands. A consumer that spawns the binary resolves it by\nspecifier, and `bin` offers a shim on `PATH` rather than a path.\n\n| Entry            | Kind   | Contents                         |\n| ---------------- | ------ | -------------------------------- |\n| `hydranium-cli`  | `bin`  | The binary — all 13 subcommands. |\n| `@hydranium/cli` | `main` | Programmatic API (see below).    |\n\nThe programmatic surface is the part of the CLI worth calling from your own scripts and tests rather\nthan through argv: `spawnDataServer` / `withDataServer` (spawn a data-server child and get a typed\nproxy, with teardown), `generateTransferModel` / `watchTransferModel` (the codegen, as a function),\nand the `runProjects` / `runQuery` / `runSave` / `runWatch` command bodies.\n\n## Status\n\nAlpha — pre-v0, not yet published. The subcommand surface and the programmatic API are both still\nmoving. See the [repository README](../../README.md) for the current status and known limitations.\n\n## License\n\n`MIT` — see this package's [`LICENSE`](./LICENSE), and the repository\n[`NOTICE.md`](../../NOTICE.md) for third-party notices.\n","readmeFilename":"README.md"}