zeekayandHanzo Dev fb32c54715 runtime: the JS toolchain is opt-in — Loader/Module are declared at the root ...

The root zip package imported zip/runtime for exactly ONE thing: the type of
Config.Loader. zip/runtime imports dop251/goja (a JS interpreter) and
evanw/esbuild/pkg/api (a JS bundler) directly, so every consumer of zip
compiled a JavaScript toolchain to name an interface — and the interface was
itself only a type ALIAS of a dependency-free leaf, internal/runtime.

Loader and Module now live where they are consumed: the zip root, next to
App.Module, which is the only thing that calls them. internal/runtime and the
zip/runtime aliases are deleted — one home, one name. zip/runtime keeps goja
and esbuild and stays the JavaScript implementation; it is simply a separate
import now, so the cost lands on the binaries that ask for JS.

There is no hot-path coupling to invert: the root only ever calls through the
interface (a.loader.LoadOne) into a loader the consumer constructs and passes
in via Config.Loader. That contract is unchanged.

Measured with `go list -deps . | wc -l` in a CLEAN module importing only zip,
outside any other module graph:

    before  315 packages, 33 of them goja + esbuild
    after   258 packages,  0
    opt-in  314 packages, 33   (a consumer that DOES import zip/runtime)

57 packages leave and none arrive: esbuild 25, goja 8, x/text 9, regexp2 3,
sourcemap 2, pprof 1, go/ast+token+scanner, archive/zip, encoding/base32,
hash/maphash — plus the two zip packages no longer reachable.

hanzoai/cloud, which imports zip/runtime nowhere, measured against this commit
vs its parent (same zip baseline, so the delta is only this change):

    cmd/cloud        402 -> 346    (JS 33 -> 0)
    cloud root       603 -> 547
    plugin/crm       605 -> 549
    plugin/storage   716 -> 664

cmd/cloud builds, and `go build ./...` yields the byte-identical error set
before and after (3 pre-existing k8s/autoscaling failures, unrelated).

Also corrected a doc claim that was already false: Config.Loader said it "is
satisfied by *extruntime.Loader". It is not, and was not before this commit —
extruntime.LoadDir returns map[string]extruntime.Module, and Go requires
IDENTICAL result types, so an equivalent method set does not satisfy the
interface. The docs now say an adapter returning zip.Module is required.

Co-authored-by: Hanzo Dev <[email protected]>

2026-07-29 17:06:24 -07:00

..

main.go

runtime: the JS toolchain is opt-in — Loader/Module are declared at the root

2026-07-29 17:06:24 -07:00