• DcRouter v32.2.0
    Release / build-and-release (push) Successful in 18m43s
    Stable

    jkunz released this 2026-09-23 00:26:48 +00:00 | 37 commits to main since this release

    2026-09-23 - 32.2.0

    Features

    • Add @serve.zone/dcrouter-apiclient, a package that carries the client half of dcrouter, the API client and the shared contracts, without the server. This release defines the package; publishing it is a separate step, described in the last point below. ts_apiclient/tspublish.json now names the package and owns ts_interfaces through folders, exporting the client at . and the contracts at ./interfaces; ts_interfaces keeps its build order and is still compiled first. A consumer that only calls the OpsServer API — gitzone testing, custom CLIs, integration suites, anything that speaks /typedrequest — declares 8 dependencies instead of the runtime package's 48, and resolves a production closure of 184 packages instead of 579. Gone from that closure: the native argon2 build, mongodb, @lossless.org/client, @design.estate/dees-catalog, @push.rocks/smartdata and @push.rocks/smartbucket. @serve.zone/dcrouter keeps its ./interfaces and ./apiclient subpath exports unchanged, so existing consumers migrate when it suits them.
      • The two folders ship as one package rather than two, because @git.zone/tspublish requires sibling packages to import each other through their published names. That bare specifier would land in dist_ts_apiclient/*.d.ts, which the runtime package also ships, and would force @serve.zone/dcrouter to declare a same-version dependency on a package cut from the same release. Owning ts_interfaces through folders keeps the existing relative import valid inside the published tarball and leaves the runtime package's exports self-contained.
      • What the new package does not shed: @push.rocks/smartproxy, @push.rocks/smartmta and @push.rocks/smartnetwork stay runtime dependencies, because contract members are typed against them (IRouteConfig, IUnifiedEmailServerOptions, IIpIntelligenceResult, and IRouteChallengeConfig from @push.rocks/smartchallenge; the gateway contracts come from @serve.zone/interfaces). A type-only import still has to resolve for a consumer's type check, so the three Rust payloads — each tarball carrying both the amd64 and the arm64 binary — are installed exactly as before, and so is @push.rocks/smartlog 3.2.2, reachable through @api.global/typedsocket, @push.rocks/smartmta, @push.rocks/smartproxy and @serve.zone/interfaces alike. The 1.1 MB figure this package is worth quoting is its own packed payload, not its install footprint.
      • Because @push.rocks/smartmta declares os: ["linux"] and cpu: ["x64", "arm64"], the new package installs on Linux x64 and arm64 only, exactly like @serve.zone/dcrouter itself. The readmes say so at the install step. This is not a dcrouter-side choice and no dcrouter change lifts it: it goes away when @push.rocks/smartproxy, @push.rocks/smartmta and @push.rocks/smartnetwork move their Rust payloads into per-platform optional packages.
      • pnpm run publish:packages runs tspublish over the repository after a release and publishes the package at the released version; @git.zone/tspublish is a dev dependency so the descriptor can also be planned and prepared locally. gitzone release keeps publishing the runtime package and qualifying the Docker images unchanged — it cannot carry a tspublish module and a Docker target in the same release.

    Maintenance

    • Build, test and release tooling on its current line: pnpm 12.4.2, @git.zone/tsbuild 4.5.1, @git.zone/tsbundle 2.14.0, @git.zone/tsdocker 3.8.1 and @git.zone/tstest 6.1.4. tsbundle 2.14.0 bundles the web UI with dcrouter's own tsconfig instead of the packaged one; the lockfile keeps one copy of each tool.
    • Git and the Docker build context ignore .env and .env.* files, so a local environment file cannot reach a commit or an image.
    Downloads