zeekayandHanzo Dev 9dd1d42ba5 build: ship the wasip1 module and the native binaries
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]>
2026-09-17 15:02:08 -07:00
2026-08-09 12:36:05 -04:00
2026-04-02 11:34:15 -04:00
2023-10-15 15:13:27 -04:00
2026-08-09 12:36:05 -04:00
2026-08-08 15:46:44 -04:00
2026-08-09 12:36:05 -04:00
2026-08-09 12:36:05 -04:00
2024-06-30 13:59:20 -04:00
2026-08-09 10:43:14 -04:00
2022-12-17 01:16:39 +00:00
2023-01-11 19:33:31 -05:00
2024-05-05 22:43:13 -04:00
2025-01-06 22:14:14 -05:00
2026-04-01 19:57:32 -04:00
2026-08-09 10:53:52 -04:00
2024-06-30 13:59:20 -04:00
2023-10-11 01:25:24 -04:00
2022-07-20 10:21:00 -04:00
2026-08-07 21:20:26 -04:00
2020-01-15 03:20:24 -08:00
2026-08-09 10:43:14 -04:00
2023-08-08 00:16:58 -04:00
2026-08-09 10:48:14 -04:00
2026-08-08 15:46:44 -04:00

esbuild: An extremely fast JavaScript bundler
Website | Getting started | Documentation | Plugins | FAQ

Why?

Our current build tools for the web are 10-100x slower than they could be:

Bar chart with benchmark results

The main goal of the esbuild bundler project is to bring about a new era of build tool performance, and create an easy-to-use modern bundler along the way.

Major features:

Check out the getting started instructions if you want to give esbuild a try.

S
Description
An extremely fast bundler for the web
Readme
31 MiB
Languages
Go 75.6%
JavaScript 17%
TypeScript 5.7%
Makefile 0.9%
HTML 0.7%