The wasm service mode is what the estate wants from this fork — a persistent
esbuild inside a stock wasip1 module, fed over the plugin protocol, needing no
filesystem at all — and nothing here built that module.
hanzo/Makefile builds it and the four native hosts, reproducibly: GOTOOLCHAIN
pinned to go.version so the compiler is the repo's pin and not the laptop's,
-trimpath, no VCS stamp, cleared build id, CGO off. Two runs of the lane give
the same digest. It is a separate file from upstream's Makefile, which stays
the development and npm lane, so a rebase touches none of this.
The version handshake was the shipping hazard. A host drives the service with
--service=<version> and cmd/esbuild/main.go exits 1 on any mismatch, so a
version written down anywhere outside the artifact can drift from it and the
drift only appears as "Cannot start service" at run time. Three things close
it. The lane reads the version from the constant that is compiled in, not from
version.txt, and refuses to build when those two disagree. Every artifact is
named for its version. And hanzo/stamp gets the version for the manifest by
starting each artifact in service mode — the .wasm under wazero with zero
preopened directories — and recording the version the artifact itself
announces, so the manifest cannot claim one the binary would reject.
.hanzo/workflows/release.yml runs the lane on main and publishes on a v* tag.
Not .github/: there is no runner there and such a job waits forever while
looking like CI.
Co-authored-by: Hanzo Dev <[email protected]>
Disjoint lineage: our fork point has the same tree as upstream 6ff1d8b0d but a
different SHA, so a plain merge would diff against the root. Merged with
upstream as a second parent and the fork-point..upstream/main patch applied, so
the tree is exactly upstream/main plus our two files.
Includes the symlink 403 for keyfile/certfile and the input-file overwrite fix.
Co-authored-by: Hanzo Dev <[email protected]>
gamut_mapping_xyz_to_srgb called srgb_to_oklab(clipped_r, clipped_b,
clipped_g) when computing the clipped color's delta from the original
during binary search, swapping g and b. The comparison color on the
next line used the correct order, so the JND check was comparing
against the wrong OKLab point and could converge on a less accurate
clipped chroma. .a{color:oklch(0.65 0.3 50)} targeting chrome90 now
lowers to #e56300 instead of #de6800.
Note: I do not consider this to be a security issue since the files in the serve directory are user-controlled. Symlinks are a useful feature for a development server and in general esbuild doesn't attempt to prevent you from serving symlinks to sensitive files. The purpose of this change is to hopefully stop AI-generated security advisories about this code. More info: https://esbuild.github.io/faq/#not-a-sandbox
github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev