[Bug]: npx t3@nightly crashes from the 2nd run, it prunes the platform package's bundled node_modules (Cannot find module '@ff-labs/fff-node')

[varo6]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Build, CI, or release tooling

Steps to reproduce

With an isolated npm cache so nothing else interferes:

CACHE=$(mktemp -d)
npx --cache "$CACHE" --yes t3@0.0.41-nightly.20260914.1700 --version   # 1st run: prints t3 v0.0.41-nightly.20260914.1700
npx --cache "$CACHE" --yes t3@0.0.41-nightly.20260914.1700 --version   # 2nd run: Error: Cannot find module '@ff-labs/fff-node'

Same thing without npx:

mkdir repro && cd repro && echo '{}' > package.json
npm install t3@0.0.41-nightly.20260914.1700   # t3 --version works
npm install                                    # "removed 11 packages"
npx t3 --version                               # Cannot find module '@ff-labs/fff-node'

Expected behavior

npx t3@nightly keeps working on every run, the way it did before the per-platform packages (#11607). In particular a systemd service with ExecStart=npx --yes t3@nightly serve ... and Restart=always should survive a restart.

Actual behavior

Only the first run after the package is extracted works. The platform package @t3code/t3-linux-x64 ships its runtime dependencies inside its own node_modules/ (published as a tarball on purpose, see the header of scripts/build-npm-platform-packages.ts). Those packages are not in the lockfile and not declared as bundleDependencies, so the next time npm reifies the same tree (the second npx in the same _npx cache dir, or any later npm install), Arborist treats them as extraneous and deletes them:

• detect-libc, ffi-rs, msgpackr-extract, node-addon-api, node-gyp-build-optional-packages, node-pty are removed.
• @ff-labs/, @msgpackr-extract/, @yuuang/ are left as empty directories.

The executable then crashes at startup on require('@ff-labs/fff-node'). With a service that has Restart=always, the first restart puts it into a permanent crash loop and the web UI is unreachable. Fixing it requires deleting the ~/.npm/_npx/<hash> directory, and it breaks again on the next restart.

#11607's verification ran npx -y t3@preview --version once per machine, which is the case that works. #11732 fixes a different upgrade break (missing t3/dist/bin.mjs) and does not touch this.

Impact

Blocks work completely

Version or commit

t3 0.0.41-nightly.20260914.1700 (@t3code/t3-linux-x64 0.0.41-nightly.20260914.1700). The preview packages (same layout since 0.0.41-preview.20260913.1669) are likely affected too; I only tested nightly.

Environment

Ubuntu 24.04.5 LTS x86_64, Node v24.14.0, npm 11.9.0. t3 runs as a systemd service: npx --yes t3@nightly serve --host 0.0.0.0 --port 3773 --no-browser.

Logs or stack traces

# 2nd npm install in the same tree
removed 11 packages in 237ms

$ ls node_modules/@t3code/t3-linux-x64/node_modules
@ff-labs  @msgpackr-extract  @yuuang
$ ls node_modules/@t3code/t3-linux-x64/node_modules/@ff-labs
(empty)

# service journal, the run right after the first successful start
Error: Cannot find module '@ff-labs/fff-node'
Require stack:
- ~/.npm/_npx/dec0da79062bfff0/node_modules/@t3code/t3-linux-x64/t3
    at Module._resolveFilename (node:internal/modules/cjs/loader:1569:15)
    ...
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '~/.npm/_npx/dec0da79062bfff0/node_modules/@t3code/t3-linux-x64/t3'
  ]
}
Node.js v26.8.2

Workaround

Pin the previous packaging, which declares these as normal dependencies: npx --yes t3@0.0.40 serve .... Alternatively delete ~/.npm/_npx/<hash> before every start (e.g. ExecStartPre), which forces a fresh extraction.

[Destreyf]

Additional finding from an attempted managed-service upgrade on Linux x64: there is a second failure after working around the missing @ff-labs/fff-node dependency.

Environment: Arch Linux x64. The existing user service was running 0.0.41-nightly.20260910.1486 under Node 24.21.0.

1. Supplying @ff-labs/fff-node@0.10.6 through NODE_PATH made the published 0.0.41-nightly.20260914.1700 executable run, and t3 update completed its install.
2. The installed runtime contained t3, client/, resource-monitor/, node_modules/, and .install-complete. Its local node_modules included @ff-labs/fff-node, so the original missing-module problem was no longer the startup failure.
3. The updater changed the active version and rewrote the systemd user unit to:

ExecStart=~/.t3/runtime/versions/0.0.41-nightly.20260914.1700/t3 __service-launcher

4. After systemctl --user daemon-reload, the service still entered a restart loop and logged:

[service-launcher] Selected t3@0.0.41-nightly.20260914.1700 runtime is missing or incomplete.

The launcher logic checks for the old runtime entrypoint at runtime/versions/<version>/node_modules/t3/dist/bin.mjs, while the new platform-package layout places the executable at runtime/versions/<version>/t3. The old Node-based launcher failed after the active-version switch for this reason, and the newly generated t3 __service-launcher unit failed with the same message after reload.

This appears independent of the npm pruning bug and is likely the service-layout issue referenced as #11732, but the two defects combine into a particularly bad upgrade path: the CLI initially cannot run, and once that is worked around, the managed service cannot boot the installed runtime.

I restored service-state.json to 0.0.41-nightly.20260910.1486 and the previous Node 24 service-launcher.mjs unit; the service returned to active (running) with HTTP 200. The Node 26 shown in the missing-module stack belongs to the new self-contained ELF executable, not the existing service Node runtime.

[juliusmarminge]

Thanks for the tight repro — this is a real packaging bug, not a duplicate of #11607 or #11732.

Confirmed. On t3@0.0.41-nightly.20260914.1700, a fresh npm install t3@… works, then a second npm install in the same tree prints removed 11 packages and t3 --version dies with Cannot find module '@ff-labs/fff-node'. After the prune, @t3code/t3-linux-x64/node_modules only has empty scoped directories (@ff-labs, @msgpackr-extract, @yuuang). That matches the report.

Cause. #11607 publishes the CLI archive bytes as @t3code/t3-<platform>-<arch>, including the archive’s runtime node_modules/ (fff-node, node-pty, ffi-rs, msgpackr-extract, …). Two things then leave those packages undeclared:

1. scripts/build-cli-archive.ts stages those deps, then deletes the stage package.json / lockfile before packing.
2. scripts/build-npm-platform-packages.ts (npmPlatformPackageManifest) writes a new manifest with os/cpu/files/preferUnplugged and no dependencies or bundleDependencies.

The tarball does ship node_modules/ (npm publish <tarball> was the workaround for npm publish <dir> stripping it). On the next reify, Arborist treats those packages as extraneous and deletes them. preferUnplugged does not stop that. This is npm working as designed; the fix is in our manifest.

#11607’s verification only ran npx once (the extract that still works). #11732 is a different upgrade break (t3/dist/bin.mjs) and does not touch this. Same layout since 0.0.41-preview.20260913.1669, so preview is almost certainly affected too. No open fix PR.

Fix. Declare the top-level shipped packages as dependencies and bundleDependencies on the platform package (same set the archive builder installs). Keep publishing tarballs. Add a test that packs a fixture, runs npm install twice, and asserts @ff-labs/fff-node still resolves.

Workaround until a new nightly: pin t3@0.0.40, or delete ~/.npm/_npx/<hash> / reinstall before each start.