One-file bundles. Every served bundle is its own process (ADR 0193), so it carries its own copy of what it imports. After the compile and the launchers, the TypeScript toolchain's esbuild (Toolchain.Bundler, run as the native binary) bundles every entrypoint in place and every launcher under its own name (--out-extension:.js=.mjs) into one ES module file, --platform=node --target=node22, the SDK inlined, a createRequire banner so inlined CommonJS finds require, shebang kept, launchers 0755, a {"type":"module"} package.json beside them. The toolchain's node_modules is copied only when an artifact names external packages (new field, TypeScript bundles only). A toolchain image without the bundler is refused by name. Launchers keep their names, so the composer is unchanged; a process running node daemon/index.js runs the bundled file.
Measured on nftables in the toolchain image: 355,377 → 7,046 bytes gzipped, 235 → 3 files; the bundled launcher served node-packet-filter.rules/reload/remove and firewall_rules from a bare node:22 container with no node_modules.
Issue 212. No new mechanism needed: build.on already passes another module's artifact by its recorded reference, and a published package records @novox/mesh-sdk@0.1.6; it also already makes a plan edge. Tests now say both (TestAPackageTheMeshPublishedIsPassedByItsExactVersion, TestAToolchainStandingOnTheSDKFollowsIt). The mesh-tools side is mesh-tools #44.
Tests: bundling invocation and no node_modules copy; external packages; full suite passes against current catalogue and mesh-host.
Merge after mesh-tools #44 has built (toolchain with esbuild), then rebuild TypeScript bundles.
**One-file bundles.** Every served bundle is its own process (ADR 0193), so it carries its own copy of what it imports. After the compile and the launchers, the TypeScript toolchain's esbuild (`Toolchain.Bundler`, run as the native binary) bundles every entrypoint in place and every launcher under its own name (`--out-extension:.js=.mjs`) into one ES module file, `--platform=node --target=node22`, the SDK inlined, a `createRequire` banner so inlined CommonJS finds `require`, shebang kept, launchers 0755, a `{"type":"module"}` package.json beside them. The toolchain's node_modules is copied only when an artifact names `external` packages (new field, TypeScript bundles only). A toolchain image without the bundler is refused by name. Launchers keep their names, so the composer is unchanged; a `process` running `node daemon/index.js` runs the bundled file.
Measured on nftables in the toolchain image: **355,377 → 7,046 bytes gzipped, 235 → 3 files**; the bundled launcher served `node-packet-filter.rules/reload/remove` and `firewall_rules` from a bare node:22 container with no node_modules.
**Issue 212.** No new mechanism needed: `build.on` already passes another module's artifact by its recorded reference, and a published package records `@novox/mesh-sdk@0.1.6`; it also already makes a plan edge. Tests now say both (`TestAPackageTheMeshPublishedIsPassedByItsExactVersion`, `TestAToolchainStandingOnTheSDKFollowsIt`). The mesh-tools side is mesh-tools #44.
Tests: bundling invocation and no node_modules copy; external packages; full suite passes against current catalogue and mesh-host.
**Merge after mesh-tools #44 has built** (toolchain with esbuild), then rebuild TypeScript bundles.
Every served bundle is its own process now, so each carries its own copy of what it imports: after
the compile and the launchers, the toolchain image's esbuild bundles every entrypoint in place and
every launcher under its own name into one ES module file, the SDK inlined, require provided to
inlined CommonJS, the launcher's shebang kept and its mode 0755. The toolchain's node_modules is
copied only for packages an artifact names external. An image without the bundler is refused by
name. Issue 212: build.on already passes a published package by its exact version and plans the
toolchain after it; tests say so.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
One-file bundles. Every served bundle is its own process (ADR 0193), so it carries its own copy of what it imports. After the compile and the launchers, the TypeScript toolchain's esbuild (
Toolchain.Bundler, run as the native binary) bundles every entrypoint in place and every launcher under its own name (--out-extension:.js=.mjs) into one ES module file,--platform=node --target=node22, the SDK inlined, acreateRequirebanner so inlined CommonJS findsrequire, shebang kept, launchers 0755, a{"type":"module"}package.json beside them. The toolchain's node_modules is copied only when an artifact namesexternalpackages (new field, TypeScript bundles only). A toolchain image without the bundler is refused by name. Launchers keep their names, so the composer is unchanged; aprocessrunningnode daemon/index.jsruns the bundled file.Measured on nftables in the toolchain image: 355,377 → 7,046 bytes gzipped, 235 → 3 files; the bundled launcher served
node-packet-filter.rules/reload/removeandfirewall_rulesfrom a bare node:22 container with no node_modules.Issue 212. No new mechanism needed:
build.onalready passes another module's artifact by its recorded reference, and a published package records@novox/mesh-sdk@0.1.6; it also already makes a plan edge. Tests now say both (TestAPackageTheMeshPublishedIsPassedByItsExactVersion,TestAToolchainStandingOnTheSDKFollowsIt). The mesh-tools side is mesh-tools #44.Tests: bundling invocation and no node_modules copy; external packages; full suite passes against current catalogue and mesh-host.
Merge after mesh-tools #44 has built (toolchain with esbuild), then rebuild TypeScript bundles.