@lenne.tech/cli 1.41.3 → 1.43.0

package/docs/commands.md

@@ -606,6 +606,46 @@ lt dev doctor
 
 ---
 
+### `lt dev vscode`
+
+Apply a verified low-memory profile to VS Code's **user** settings. Targets the per-workspace TypeScript servers, which dominate memory once several monorepos are open at once: every workspace root spawns its own semantic TS server, so eight monorepos with an `api` and an `app` root each add up to 16 of them.
+
+**Usage:**
+```bash
+lt dev vscode              # preview, then apply after confirmation
+lt dev vscode --dry-run    # show the diff, write nothing
+lt dev vscode --explain    # print the profile with reasons + the keys left out on purpose
+lt dev vscode --revert     # remove the profile keys again
+lt dev vscode --variant cursor   # limit to one: code | insiders | cursor | vscodium
+lt dev vscode --noConfirm  # skip the confirmation prompt
+```
+
+**Alias:** `lt d vsc`
+
+**Profile:**
+
+| Key | Value | Why |
+|---|---|---|
+| `typescript.tsserver.maxTsServerMemory` | 2048 | Per-server heap ceiling; the default is 3072 and multiplies across every open root |
+| `typescript.preferences.includePackageJsonAutoImports` | `off` | Auto-import stops scanning every package.json — the largest monorepo win |
+| `typescript.disableAutomaticTypeAcquisition` | `true` | Skips the `@types` download/scan pass |
+| `files.watcherExclude` | node_modules, dist, `.nuxt*`, `.output*`, .git internals | Keeps the file watcher off generated trees |
+| `search.exclude` | node_modules, dist, `.nuxt*`, `.output*` | Keeps full-text search from indexing them |
+
+The globs are `.nuxt*` / `.output*`, not the bare names: a glob segment matches whole path segments, so `**/.nuxt/**` would leave the sibling build dirs (`.nuxt-check` from the check chain, `.nuxt-test` / `.output-test` from `lt dev test`) watched and indexed — and a `.output-test` tree is 37-294 MB.
+
+**Safety:** JSONC-aware via `jsonc-parser`, so comments and formatting in a hand-maintained `settings.json` survive. Refuses to write into a file it cannot parse or a symlink, backs up to `settings.json.bak` (the **first** backup is kept, so a later run — including `--revert` — cannot overwrite the record of the pre-tuning state), and merges the object-valued exclude maps so hand-added entries are kept. Re-running is a true no-op.
+
+**`--revert`** subtracts only the entries this profile contributed, so a hand-maintained exclusion is never removed along with them. For the scalar keys it deletes the key, restoring VS Code's own default — an explicit value that preceded the tuning is not restored; that is what the `.bak` is for.
+
+**Detects:** VS Code, VS Code Insiders, Cursor, VSCodium — every variant whose user settings file exists.
+
+**After applying**, restart VS Code (or run *Developer: Reload Window*) — the TypeScript servers read these settings at startup, so nothing changes until they do.
+
+Run `--explain` to see three commonly recommended keys the profile deliberately omits, each with the manifest check or measurement that ruled it out.
+
+---
+
 ### `lt dev test`
 
 One-shot E2E wrapper: ensure `up`, wait for the App URL, run `pnpm run test:e2e` with the `.lt-dev/.env` bridge loaded. Optional teardown after.
@@ -649,7 +689,37 @@ lt dev test -- --ui spec.ts      # everything after `--` is forwarded to playwri
 | `LT_DEV_ACTIVE`, `LT_DEV_DB_NAME` | Marker keys for consumers |
 | `NODE_EXTRA_CA_CERTS` | Path to Caddy's root CA cert (auto-detected) |
 
-`lt dev init` injects a tiny `// >>> lt-dev:bridge >>>` block at the top of `playwright.config.ts` that loads this file at config-load time — making Playwright (CLI, IDE, VS Code extension) automatically use the `lt dev` URLs and trust the local CA, without inheriting the parent shell.
+Additionally, `lt dev test` exports two build-directory keys into the app process it
+spawns. They are **not** written to the bridge file — they scope one run, not the
+project:
+
+| Key | Value | Why |
+|-----|-------|-----|
+| `NUXT_BUILD_DIR` | `.nuxt-test` | Nuxt holds its lock on the build dir (`acquireLock(nuxt.options.buildDir)`). Sharing `.nuxt` with a parked `nuxt dev` did not interleave writes — it made the test build **abort** with "Another Nuxt dev is already running", so the app never came up and every spec failed on a missing selector. That reads like broken specs while being pure infrastructure. |
+| `NITRO_OUTPUT_DIR` | `.output-test` | A separate axis: `buildDir` and Nitro's `output.dir` are unrelated knobs. `lt dev test` serves the production bundle, so it rebuilds on every run and used to overwrite the `.output` a local `pnpm run build` was using. |
+
+**The project must forward both**, or the isolation silently degrades to the shared
+directories. `nuxt-base-starter` ≥ 2.16.0 does this out of the box:
+
+```ts
+// nuxt.config.ts
+buildDir: process.env.NUXT_BUILD_DIR || '.nuxt',
+nitro: { output: { dir: process.env.NITRO_OUTPUT_DIR || '.output' } },
+```
+
+**Neither key is framework-native**, despite the prefixes — verified against
+`@nuxt/schema`, `nitropack` and `c12`: none of them reads `NUXT_BUILD_DIR` or
+`NITRO_OUTPUT_DIR`. Both levers are opened by the project's own `nuxt.config.ts`,
+which is why the two-line snippet above is required rather than optional. (Singling
+one of them out as "not a framework feature" reads as if the other one were, and a
+reader acting on that forwards only half — leaving exactly the collision this
+section exists to prevent.) For projects that have not adopted it, the CLI keeps a
+`.output/server/index.mjs` fallback when locating the built server.
+
+A project that ignores both keys still works; it just loses the isolation, so a
+`lt dev test` run and a parked `nuxt dev` collide again.
+
+`lt dev init` injects a tiny `// >>> lt-dev:bridge v2 >>>` block at the top of `playwright.config.ts` that loads this file at config-load time — making Playwright (CLI, IDE, VS Code extension) automatically use the `lt dev` URLs and trust the local CA, without inheriting the parent shell.
 
 `lt dev down` removes the bridge file so subsequent runs without `lt dev up` fall back cleanly to the classic `localhost:3000`/`localhost:3001` defaults.
 
@@ -1005,6 +1075,15 @@ Installs helper scripts:
 
 ### `lt fullstack init`
 
+**Exit codes.** `0` on success, `1` on any failure — a failed clone, an aborted
+`pnpm install`, an invalid flag value, an existing target directory. Until 1.43.0
+every one of those exited `0`, so `lt fullstack init … && echo ok` printed `ok`
+after a broken scaffold; scripts and CI jobs that check `$?` need no workaround
+any more. The same contract holds for `lt fullstack add-api` / `add-app`, which
+`init` delegates to inside an existing workspace. A cancelled interactive prompt
+is not a failure and still exits `0`.
+
+
 Creates a new fullstack workspace with API and frontend.
 
 **Usage:**
@@ -1127,6 +1206,36 @@ lt fullstack add-app [options]
 
 ---
 
+### `lt fullstack update`
+
+Prints the mode-specific update entry points for backend and frontend — **and repairs generated project scaffolding on the way**. The name undersells it: this command writes files.
+
+**Usage:**
+```bash
+lt fullstack update
+```
+
+**Self-heals** (each is idempotent and a no-op when nothing is wrong):
+
+| What | Why it needs healing |
+|---|---|
+| `.gitignore` — adds `.lt-dev/` | Added after many projects were scaffolded |
+| `check` wrapper script | Same |
+| Vendor `CLAUDE.md` | Same |
+| `migrations-utils/migrate.js` | Written **once**, at vendor-conversion time. It is project scaffolding, not `src/core/`, so no update path ever revisits it — a project converted before the template stopped requiring `ts-node` unconditionally keeps the broken file forever, and every deployed container then dies with `Cannot find module 'ts-node'` before applying a single migration (silently, because the entrypoint degrades a migration failure to a warning on purpose). |
+
+The migration-store repair is deliberately narrow. It acts **only** when the `require('./ts-compiler')` is a top-level, unconditional statement — the one shape that provably cannot survive a production image where `ts-node` was pruned. Any conditional form (inside `try`, `if`, a function, a ternary) is the project's own working solution and is left untouched, because the replacement is not behaviour-neutral: the bundled template hardcodes the collection name and takes its URI from `./mongo-uri`, so overwriting a customized store would empty the migration ledger and re-run every historical migration.
+
+Before overwriting, the command establishes that the change is undoable. A file that git tracks and that is unmodified is simply replaced (git has the copy). A file git cannot recover — untracked, `.gitignore`d, or outside a repo — gets a `.bak` first. A tracked file with **uncommitted** changes is never touched and is reported as skipped:
+
+```
+migrations-utils/migrate.js (skipped: uncommitted changes — commit or discard them, then re-run)
+```
+
+That skip line is the only signal that a repair was needed but not applied — commit or discard, then re-run.
+
+---
+
 ### `lt fullstack convert-mode`
 
 Convert **both** backend (`projects/api/`) and frontend (`projects/app/`) of a fullstack monorepo between npm mode and vendor mode in a single command. Auto-detects the subprojects, shows the plan for each side, and orchestrates the backend + frontend conversions sequentially.
@@ -1220,6 +1329,36 @@ them from the TurboOps stage env at runtime, so nothing is patched there):
 `environment.ts` (local dev) is never touched. Only the URL origin is replaced, so
 custom paths (`/v2/graphql`) survive and a re-run with a new domain updates them.
 
+#### Database host: always stack-prefixed, never bare `mongo`
+
+The printed checklist spells the DB URI out per stage, and the exact host matters:
+
+```
+NSC__MONGOOSE__URI=mongodb://<user>:<pass>@<project>-production_mongo:27017/<db>?authSource=admin
+NSC__MONGOOSE__URI=mongodb://<user>:<pass>@<project>-dev_mongo:27017/<db>?authSource=admin
+```
+
+**Never `mongodb://mongo:27017/<db>`.** The project's own `docker-compose.yml` names
+the service `mongo`, which makes the short name the obvious guess — and the wrong
+one. TurboOps deploys every stack onto a shared overlay network, where the bare
+service name is an alias that *every* stack's `mongo` answers to. The connection
+then lands on a foreign project's database, and on a different one per connection.
+
+The symptoms do not look like a configuration problem: writes split across two
+databases, sessions that vanish after a reconnect, files whose bytes are "sometimes"
+missing. Meanwhile the application's own database sits empty. A project lost a day of
+debugging to this (DEV-2140) with the application code fully correct.
+
+TurboOps rejects bare DB hosts and isolates bare-named DB services from the shared
+overlay since v1.72.0 — but only from that version, and only for stacks deployed
+after it. The stack-prefixed host is correct either way, so use it unconditionally.
+
+The prefix fixes **which** database you reach, not **who** may reach it: the overlay
+network stays shared, so the database credentials are the actual boundary. Give the
+mongo service a user and password and connect with
+`mongodb://<user>:<pass>@<project>-<stage>_mongo:27017/<db>?authSource=admin` — an
+unauthenticated instance is readable and writable by every co-tenant stack.
+
 **Usage:**
 ```bash
 lt deployment create [name] [domain] [options]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lenne.tech/cli",
-  "version": "1.41.3",
+  "version": "1.43.0",
   "description": "lenne.Tech CLI: lt",
   "keywords": [
     "lenne.Tech",
@@ -57,19 +57,20 @@
     "bin"
   ],
   "dependencies": {
-    "@aws-sdk/client-s3": "3.1090.0",
+    "@aws-sdk/client-s3": "3.1100.0",
     "@lenne.tech/cli-plugin-helper": "0.0.14",
-    "axios": "1.18.1",
+    "axios": "1.19.0",
     "bcrypt": "6.0.0",
-    "defuddle": "0.19.1",
+    "defuddle": "0.19.2",
     "glob": "13.0.6",
     "gluegun": "5.2.2",
-    "js-sha256": "0.11.1",
-    "js-yaml": "4.3.0",
+    "js-sha256": "1.0.0",
+    "js-yaml": "4.3.1",
     "jsdom": "29.1.1",
+    "jsonc-parser": "3.3.1",
     "lodash": "4.18.1",
     "open": "11.0.0",
-    "playwright-core": "1.61.1",
+    "playwright-core": "1.62.1",
     "ts-morph": "28.0.0",
     "ts-node": "10.9.2",
     "turndown": "7.2.4",
@@ -77,39 +78,57 @@
     "typescript": "6.0.3"
   },
   "devDependencies": {
-    "@lenne.tech/eslint-config-ts": "2.1.4",
+    "@lenne.tech/eslint-config-ts": "2.3.0",
     "@lenne.tech/npm-package-helper": "0.0.12",
     "@types/ejs": "3.1.5",
     "@types/jest": "30.0.0",
     "@types/js-yaml": "4.0.9",
     "@types/jsdom": "28.0.1",
     "@types/lodash": "4.17.24",
-    "@types/node": "26.1.1",
+    "@types/node": "26.1.2",
     "@types/turndown": "5.0.6",
     "ejs": "6.0.1",
-    "eslint": "9.39.4",
+    "eslint": "10.8.0",
     "husky": "9.1.7",
     "jest": "30.4.2",
+    "minimatch": "10.2.6",
     "prettier": "3.8.3",
     "rimraf": "6.1.3",
-    "ts-jest": "29.4.11"
+    "ts-jest": "29.4.12"
   },
   "//overrides": {
     "semver@*": "Force latest semver 7.x across all sub-deps; gluegun@5.2.2 pins semver@7.7.0 which is stale - remove once gluegun updates its dep.",
-    "brace-expansion@<1.1.16": "DoS via exponential-time expansion of consecutive non-expanding {} groups (GHSA-3jxr-9vmj-r5cp, high). Transitive via dotgitignore/eslint/fs-jetpack/glob/test-exclude > minimatch. One bounded key per affected major so each can only raise a vulnerable version, never cap a patched one - remove once minimatch requests the patched ranges.",
-    "brace-expansion@>=2.0.0 <2.1.2": "Same advisory, 2.x line.",
-    "brace-expansion@>=5.0.0 <5.0.7": "Same advisory, 5.x line. Floored at >=5.0.0 so a future 3.x/4.x dependency is not silently forced across two majors."
+    "brace-expansion@<1.1.18": "Two DoS advisories: exponential-time expansion of consecutive non-expanding {} groups (GHSA-3jxr-9vmj-r5cp, high) and unbounded expansion length causing an OOM crash (GHSA-mh99-v99m-4gvg, high). Transitive via dotgitignore/eslint/fs-jetpack/glob/test-exclude/ts-morph > minimatch. One bounded key per affected major so each can only raise a vulnerable version, never cap a patched one - remove once minimatch requests the patched ranges.",
+    "brace-expansion@>=2.0.0 <2.1.4": "Same advisories, 2.x line.",
+    "brace-expansion@>=5.0.0 <5.0.9": "Same advisories, 5.x line. Floored at >=5.0.0 so a future 3.x/4.x dependency is not silently forced across two majors.",
+    "//minimatch-note": "brace-expansion 1.x and 2.x are END OF LINE for GHSA-mh99-v99m-4gvg: the advisory range is <=5.0.7 across ALL majors and upstream patched ONLY 5.0.8+. 1.1.18 and 2.1.4 are the newest releases of their majors and remain vulnerable. Forcing brace-expansion 5.x globally is NOT an option: 5.x is ESM/tshy and exports an object ({ expand, ... }) while 1.x/2.x export the function itself, so minimatch 3.x/5.x would die on `expand is not a function`. The only real fix is to raise each CONSUMER off minimatch 3.x/5.x, which is what the scoped entries below do. Each was verified against the consumer's actual call site before being added. The eslint / @eslint/eslintrc / @eslint/config-array entries were REMOVED in 1.42.0: eslint 10 requests minimatch ^10.2.5 itself, config-array ^10.2.4, and eslintrc is no longer in the tree at all.",
+    "minimatch@>=4 <10": "Bounded raise of every minimatch 4.x-9.x install to 10.2.6, whose brace-expansion ^5.0.8 is patched. Covers filelist (gluegun > ejs > jake > filelist, PRODUCTION-reachable, minimatch ^5.0.1), @typescript-eslint/typescript-estree (^9.0.4) and jest-config/jest-runtime/@jest/reporters (^9). Verified safe per consumer: filelist calls only the static helper `minimatch.match(files, pat, opts)`; typescript-estree calls the named `minimatch(filePath, pattern, { dot: true })`; the three jest packages declare minimatch but never require it. Floored at >=4 so the 3.x line is NOT swept in: minimatch 3.x is callable while 9.x/10.x export an object with __esModule but no `default` key, so sweeping it would break any consumer that calls the default export. Drop once these consumers request minimatch >=10 themselves.",
+    "babel-plugin-istanbul > test-exclude@<8": "test-exclude 6.0.0 pins minimatch ^3.0.4 and glob ^7. test-exclude 8.0.0 uses minimatch ^10.2.2 + glob ^13 (the glob major this project already ships) and is still CJS with the same `module.exports = TestExclude` class shape, so babel-plugin-istanbul's _interopRequireDefault + `new TestExclude(opts)` keeps working. Drop once babel-plugin-istanbul widens its ^6.0.0 range.",
+    "fs-jetpack > minimatch@<10": "Same chain, PRODUCTION-reachable (gluegun > fs-jetpack). Safe: lib/utils/matcher.js does `require('minimatch').Minimatch` and uses only `new Minimatch(pattern, { matchBase, nocomment, nocase, dot })`, `.negate` and `.match()` - all verified against 10.x. Not fixable by upgrading fs-jetpack: gluegun@5.2.2 is the latest release and fs-jetpack@5.1.0 still requests minimatch ^5.1.0 (brace-expansion ^2.0.1, also unpatched).",
+    "@istanbuljs/load-nyc-config": "GHSA-5p4m-2wfm-xmqj (high): quadratic CPU consumption resolving !!omap. Patched only in 4.3.1 - the advisory states the fix was NOT backported to 3.x, so 3.15.0 is the end of its line and there is nothing to raise it to within the major. The one 3.x path is dev-only: ts-jest > @jest/transform > babel-plugin-istanbul > @istanbuljs/load-nyc-config > js-yaml@3.15.0. Cross-major export shape verified before adding (repo policy): load-nyc-config calls `require('js-yaml').load(...)` at index.js:80, and 4.x exports `load` - so the raise is API-compatible. It is also strictly SAFER: 4.x `load` behaves like 3.x `safeLoad`, refusing arbitrary type construction, and the input here is a repo-local .nycrc.yml. Scoped to this ONE consumer rather than raised globally: that is the call site whose shape was verified, and a global raise would silently apply to consumers nobody checked. A top-level `js-yaml@<4.3.1` selector was tried first and npm did not apply it to this nested path at all - the scoped form is what actually resolves. Remove once ts-jest's istanbul chain requests a patched js-yaml itself."
   },
   "overrides": {
     "semver@*": "7.8.5",
-    "brace-expansion@<1.1.16": "1.1.16",
-    "brace-expansion@>=2.0.0 <2.1.2": "2.1.2",
-    "brace-expansion@>=5.0.0 <5.0.7": "5.0.7"
+    "brace-expansion@<1.1.18": "1.1.18",
+    "brace-expansion@>=2.0.0 <2.1.4": "2.1.4",
+    "brace-expansion@>=5.0.0 <5.0.9": "5.0.9",
+    "fs-jetpack": {
+      "minimatch@<10": "10.2.6"
+    },
+    "babel-plugin-istanbul": {
+      "test-exclude@<8": "8.0.0"
+    },
+    "minimatch@>=4 <10": "10.2.6",
+    "@istanbuljs/load-nyc-config": {
+      "js-yaml": "4.3.1"
+    }
   },
+  "//jest.workerIdleMemoryLimit": "Recycle a ts-jest worker once its heap passes this. Guards against an intermittent `A jest worker process was terminated by another process: signal=SIGSEGV` that kills ONE suite while every other test passes (seen twice in marketplace*, both under `npm run check`, never reproducible on demand - 0 in 9 targeted runs incl. --maxWorkers=16). It is a worker crash, NOT an assertion failure: the signature is `Test suite failed to run` with the remaining count still green. All versions are current and in-range (node 24 / jest 30 / ts-jest 29 / ts 6), so this is a resilience measure against unbounded worker heap growth, not a proven root-cause fix - if it recurs, capture the suite name and re-open.",
   "jest": {
     "testEnvironment": "node",
     "rootDir": "__tests__",
     "testTimeout": 60000,
+    "workerIdleMemoryLimit": "512MB",
     "testMatch": [
       "<rootDir>/*.test.ts"
     ],