Nub — Fast TypeScript/Node Toolchain

Code name: nub

Installs nub: a single Rust binary that runs TypeScript/JavaScript files, package.json scripts, and local CLIs directly on top of the Node.js and package manager already in the container — no new runtime, no lock-in.

Also included automatically: repairs broken host paths in your git config and restores your SSH commit-signing key on every attach, on both local and cloud containers, with nothing to set up on your end — see helpers4-common for how it works.

Why this feature exists

nub is explicitly not a replacement runtime: “runs on the node and package manager you already have.” It accelerates three things that are normally slow because of Node’s own CLI-wrapper overhead:

• Running a .ts/.js file directly (nub file.ts) — faster startup than tsx/ts-node, full tsconfig.json support.
• Running a package.json script (nub run <script>) — faster than npm run/pnpm run.
• Running a local CLI binary (nubx <cli>) — faster than npx <cli>, no Node wrapper.

It also has its own dependency installer (nub install) with a unified interface across npm/pnpm/bun lockfiles, and its own Node-version manager — this feature deliberately doesn’t use the latter. Node’s own version is already this container’s responsibility via the official node feature (dependsOn below); letting nub node install manage a second, independent version would create two competing version-selection mechanisms in the same container. Use nub for the speed, not for the version management.

Compatibility with pnpm-store

nub install doesn’t shell out to the real pnpm binary — it resolves a pnpm-lock.yaml with its own embedded engine. Verified directly (real container, inode comparison, and an offline reinstall with nub’s own cache wiped): when pnpm-store is also installed, nub reads the same store-dir/storeDir config and hardlinks package content from that shared store instead of duplicating it — a package fetched once is reused, and survives a rebuild via pnpm-store’s named volume, exactly like a real pnpm install would. The two features are safe to combine.

Example Usage

{
  "features": {
    "ghcr.io/helpers4/devcontainer/nub:1": {}
  }
}

Pin a specific release instead of the default latest:

{
  "features": {
    "ghcr.io/helpers4/devcontainer/nub:1": {
      "version": "1.2.3"
    }
  }
}

Options

Option	Type	Default	Description
version	string	latest	Version of nub to install, or a specific release like 1.2.3.
installGlobally	boolean	true	Symlink nub/nubx into /usr/local/bin so they’re available system-wide (all users, root, sudo) without relying on the target user’s own $PATH.

How it works

1. Runs the official installer as the container’s target non-root user (not root — the installer resolves its default install location from $HOME), with NUB_INSTALL_DIR=~/.nub and NUB_NO_MODIFY_PATH=1 so it never edits ~/.bashrc/~/.zshrc itself.
2. If installGlobally (default), symlinks every binary under ~/.nub/bin/ (nub and nubx, the latter dispatching on argv[0]) into /usr/local/bin.

No VS Code extension — nub doesn’t have one. This feature is CLI tooling only.

What this feature does not do

• Does not install the nub npm/pnpm shims (nub pm shim, which hardlinks ~/.nub/shims/{npm,npx,…} to transparently intercept package-manager calls). That’s a deeper, PATH-wide interception decision left to the consuming project to opt into explicitly — this feature only makes the nub/nubx binaries available.
• Does not manage Node versions. See “Why this feature exists” above.

Links

• nub: https://nubjs.com/
• Docs: https://nubjs.com/docs
• Source: https://github.com/nubjs/nub

Version History

• v1.2.3: Documentation only, no functional change — added a “Compatibility with pnpm-store” section documenting a verified finding: nub install hardlinks package content from pnpm-store’s shared store instead of duplicating it.
• v1.2.2: Documentation only, no functional change — the previous wording sweep made the JSON description field far too long, shifting focus away from the feature itself onto the self-heal side benefit. Shortened to 5 words and kept generic (no implementation detail like “git config”), matching the original’s brevity and level of detail.
• v1.2.1: Documentation only, no functional change — the self-heal callout above (and the JSON description field) led with internal jargon (“helpers4’s self-heal”) instead of the actual benefit; reworded to lead with what it does, with the full mechanism staying in helpers4-common’s own README.
• v1.2.0: Documentation only, no functional change — mentions that helpers4-common’s automatic git-config self-heal (see above) now comes along with this feature.
• v1.1.0: Switched from an inline copy of helpers4-common’s bootstrap (user detection, apt helpers) to a direct dependsOn on the helpers4-common feature — no behavior change, just a single source of truth for that logic instead of a copy every feature had to keep in sync.
• v1.0.0: Initial release.