Zipp releases

Latest: v0.0.29, 23 October 2026

An embedded script's error positions are its own and a syntax error says where it is, a sandbox's host requests are bounded and cancellable, and a permitted redirect is checked before it is followed. A large script keeps one copy of its source, and zipp js keeps its compiled code between runs: TypeScript's peak working set falls from 349 to 310 MiB, and run again its workload finishes in 0.83 s instead of 1.14 s. The benchmarks page shows v0.0.28's profile-guided capture; the release notes give this release's measurements.

• Embedding: lines and columns count from the host's own text (in the browser engine an app's line N had read N+154); setScriptOrigin(name, lineOffset, columnOffset) names a script and moves its positions as Node's vm.Script options do, the preamble's own frames read zipp:preamble, and a syntax error gives its position. Natively, embed::ScriptOrigin does the same.
• Sandbox: with permissions.network.redirects: true, each redirect's destination is checked against the allowlist before it is requested (an origin the allowlist does not name had received the request first); host requests run at most 64 at once, each with an AbortSignal, and close() settles every run still waiting on one. Loader 1.3.0, host SDK 1.4.0.
• Fixes: a class evaluated more than once resolves super and its own name against its own evaluation; a heap ceiling no longer convicts a script on garbage a major collection would free, or on slot tables doubled to hold it (both in v0.0.28 as well); Python's / on two ints rounds once, as CPython's does, in on two ASCII strings takes linear time, and in on a range or bytes follows CPython; TextDecoder keeps its stream state.
• Interpreter: inherited reads, private fields and x == null are faster, and the 78 benchmark programs take 0.99× v0.0.28's time interpreted and 0.98× with the JIT. zipp js keeps the compiled code of a script of 32 KiB or more in the per-user cache folder; ZIPP_CACHE_DIR= set to empty turns that off.
• WebAssembly size: as published, the JavaScript engine is 1.24 MB on the wire, ZIPP Lite 0.75 MB, Python without torch 1.63 MB and the complete engine 2.01 MB; the torch package 0.40 MB. The engines are 0.2% to 0.5% larger on the wire than v0.0.28's.

Release notes and downloads on GitHub · docs/releases/0.0.29.md · v0.0.28 notes · v0.0.27 notes · v0.0.26 notes · v0.0.25 notes · v0.0.24 notes · v0.0.23 notes

Install

# Windows: the portable .exe runs from wherever you saved it
.\zipp-0.0.29-windows-x86_64-portable.exe js app.js
# or install zipp-0.0.29-windows-x86_64-installer.msi, which adds zipp to
# your PATH without administrator rights
zipp js app.js

# Linux x86-64 (zipp-0.0.29-linux-arm64 or -linux-armv7 on Arm), glibc 2.35+
curl -fL -o zipp https://github.com/f2i-com/zipp.org/releases/download/v0.0.29/zipp-0.0.29-linux-x86_64
chmod +x zipp
./zipp js app.js

# WebAssembly, for a web page: the loader zipp.mjs from the embed kit, and one
# engine (or its .wasm.br: the same engine, about a quarter of the size)
curl -fLO https://github.com/f2i-com/zipp.org/releases/download/v0.0.29/zipp-0.0.29-wasm-embed-kit.zip
unzip -j zipp-0.0.29-wasm-embed-kit.zip zipp-0.0.29-wasm-embed-kit/zipp.mjs
curl -fLO https://github.com/f2i-com/zipp.org/releases/download/v0.0.29/zipp-0.0.29-javascript.wasm

# From source, any platform with Rust 1.92
git clone https://github.com/f2i-com/zipp.org && cd zipp.org
cargo build --locked --release
./target/release/zipp --version --json

Zipp is not on crates.io or npm yet. The WebAssembly engines and the embed kit are meant to be served by your own host, over HTTP: a page needs zipp.mjs from the kit beside whichever .wasm it loads. Serve a .wasm.br with Content-Encoding: br and Content-Type: application/wasm and the browser decodes it; zipp.mjs 1.2.0 also loads one itself, decompressing it where the runtime can or falling back to the plain .wasm beside it. The embed section of the home page has a starter project, and the WebAssembly page explains the loader, its sandboxes and the Worker model.

Up to v0.0.25 the downloads were archives: zipp-<v>-x86_64-pc-windows-msvc.zip for Windows, zipp-<v>-x86_64-unknown-linux-gnu.tar.gz for Linux, which unpacks to a folder holding zipp, and zipp-wasm-<v>-web.zip and its siblings for the WebAssembly engines. From v0.0.26 they are the plain files above, and the WebAssembly page describes the engine files and the embed kit.

What a release has to pass

Pushing a vX.Y.Z tag runs the release workflow. It refuses to publish unless the tag object matches the checkout; the root Cargo.toml, the WebAssembly crate and the landing page all carry the same version; and the reusable CI, the full security workflow (including the pinned Test262 corpus), the native build and the WebAssembly build all pass at that exact commit. A green main at some other revision is not a release gate. The job is retry-safe: it re-downloads existing assets, verifies SHA256SUMS, and checks that BUILD-INFO.json is not dirty and names the right commit before deciding to do nothing. A dispatched re-run may skip the two longest gate jobs - the native workspace suite and Test262 - only when the identical tree has been through them elsewhere; v0.0.19 was published that way, with both run locally on the tagged commit (308 test binaries, 2,453 tests; 95,680 of 95,680 corrected-core executions) and every other job in the workflow, and so was v0.0.20, whose JavaScript engine source had not changed since v0.0.19 passed them. From v0.0.21 the workflow also builds the torch package with the two engines it pairs with, and refuses to publish unless python plus the package prints exactly what all prints over the torch suites. From v0.0.22 it also builds ZIPP Lite. v0.0.24's first run lost four gate jobs to GitHub runner shutdowns, and those jobs were re-run at the same commit before it published. v0.0.27 was dispatched the same way: its tagged commit changes only versions and release notes from 05d2bd9b, where the full security workflow, the native workspace suite and Test262 on 64-bit and 32-bit builds included, had passed. So was v0.0.28, after the CI and the full security workflow had passed on its tagged commit itself. So was v0.0.29: the full security workflow on its prep commit, 8cd844fd, had failed one test, a heap-ceiling regression, whose fix and the heap and limit tests around it were run before 58c92a59 was tagged, and Test262 then passed on the published Windows binary, with its JIT and without.

All releases

Release notes for v0.0.1 through v0.0.17 live in the annotated tag messages; v0.0.18 is the first with a notes file in docs/releases/, and from v0.0.20 that file is the GitHub release body verbatim. The engineering journal tells the story between the tags.