jsvu: JavaScript engine binaries without the build step

Installing eight JavaScript engines and the PATH step that makes them available

jsvu solves a problem that anyone testing JavaScript engine behaviour across multiple runtimes eventually hits: getting a fresh binary for V8, SpiderMonkey or JavaScriptCore without waiting for a compiler to finish. Compiling any of these engines from source requires each project's own toolchain and build environment. jsvu sidesteps all of that by fetching precompiled binaries.

Node.js v18 or newer is required, which the package.json confirms with `"node": ">=18.0.0"`. Install jsvu globally:

npm install jsvu -g

Binaries land in `~/.jsvu/bin`, but that directory is not on PATH by default. Adding it to your shell config, for example `~/.bashrc`, makes the engine names available as commands:

export PATH="${HOME}/.jsvu/bin:${PATH}"

Running `jsvu` without arguments on first use starts an interactive session that asks for the operating system, the architecture, and which engines to manage. Once answered, jsvu downloads the latest version of each selected engine. On later runs, the same command updates everything that is already installed.

Engine availability by platform: four engines cover every combination, four do not

Eight engines are supported, but the platform coverage is not uniform across them. A table in the README maps each engine against six platform combinations: mac64, mac64arm, win32, win64, linux32 and linux64. V8, V8 debug, SpiderMonkey and QuickJS-ng each have a binary for all six of those combinations, with no platform restrictions in the table. The other four do not.

GraalJS does not have a mac64arm binary, which means Apple Silicon Macs get no GraalJS through jsvu. It runs on mac64 (Intel Macs), win64 and linux64 only. Hermes and XS cover the same four platforms: mac64, mac64arm, win64 and linux64, with no win32 or linux32 binary for either. JavaScriptCore has the same mac and Linux coverage as Hermes, but its win64 entry carries a footnote about external dependencies that is described in the next section.

No gap in the table is presented as temporary or as a pending addition. If a combination you need shows an unavailable marker, no workaround or fallback is documented anywhere in the project.

The JavaScriptCore footnote gives win32 setup instructions the support table says are not needed

For JavaScriptCore on 64-bit Windows, the win64 entry in the support table carries a footnote. On 64-bit Windows, the user must download the latest WebKitRequirements from the WebKitForWindows repository and add its `bin64` directory to PATH before the engine will run. That manual step is not automated by jsvu, and the table treats win64 as a supported combination only with that dependency satisfied.

The same footnote also addresses 32-bit Windows, saying to install iTunes before running JavaScriptCore on that platform. That instruction is worth reading closely alongside the table, because the table marks JavaScriptCore on win32 as unavailable, using the same marker as all other engine-platform combinations that have no working binary. A reader checking the table alone would conclude that JavaScriptCore on win32 is not supported at all. Yet the footnote gives an explicit iTunes dependency step for that same platform.

Those two pieces of information cannot both be accurate without further explanation, and none is given. Whether the footnote documents an arrangement that predates the table entry being marked unavailable, or whether the table was updated without removing the footnote, the README leaves the contradiction in place. The table and the footnote disagree on win32, and the project does not clarify which one is current.

Bypassing the interactive prompt in CI with --os and --engines

On a personal machine, the interactive first-run prompt is simple to work through. In a CI pipeline, a prompt waiting for keyboard input will hang the job indefinitely, so two flags bypass it:

jsvu --os=linux64 --engines=all

Passing `--engines=all` is equivalent to listing `graaljs,hermes,javascriptcore,quickjs,spidermonkey,v8,xs` by name. One engine is absent from that expansion: `--engines=all` does not install the v8-debug binaries. Any pipeline that needs v8-debug must list it explicitly alongside whichever other engines are required.

When the runner platform is not known in advance, `--os=default` attempts to detect it from the running environment. One known case where this detection can produce a wrong answer is a 32-bit Node.js process running on a 64-bit machine, where the detected OS value may not match the actual architecture and jsvu may attempt to fetch binaries for the wrong target.

Pinning a specific engine version alongside the latest, and V8's milestone shorthand

jsvu also installs older versions for test cases that must reproduce behaviour at a known point. The syntax pairs the engine name with a version number:

jsvu [email protected]

Binaries installed using this method are named `${BINARY}-${VERSION}`, so the example above installs a binary named `v8-7.2.502`. This way, there's never any conflict with the main `v8` binary, which jsvu can keep up to date. The pattern works for each engine:

jsvu [email protected]
jsvu [email protected]
jsvu javascriptcore@242640
jsvu [email protected]

If a version number is invalid or no precompiled binary exists for that version, jsvu shows an error.

For V8 and V8 debug only, jsvu also accepts a partial milestone:

jsvu [email protected]

jsvu figures out that this means v7.2.502, and then installs that version. That feature is documented only for V8 and V8 debug, not for GraalJS, Hermes, QuickJS-ng, SpiderMonkey, JavaScriptCore or XS.

eshost-cli connects jsvu installs to a cross-engine test runner

jsvu pairs with eshost-cli, a separate npm package that runs a JavaScript snippet across multiple engines and returns each result separately. After installing eshost-cli globally, one command registers all jsvu-installed engines automatically:

eshost --configure-jsvu

For finer control, individual `eshost --add` commands point to specific paths under `~/.jsvu/bin/` on Linux and Mac, or under `%USERPROFILE%\.jsvu\bin\` on Windows. Both sets of commands, including extra flags like `--args '--harmony'` for a V8 harmony build, are spelled out in the project README for each supported engine.

Once configured, running a snippet across all registered engines looks like this:

eshost -e 'Date.parse("1 Octopus 2018")'

Each engine's output appears on a separate line, making divergences visible in a single step. Without jsvu, each engine would need a separate install procedure from a different source.

The Security cons section in the README is a heading with no content

The README closes with the heading `## Security cons`. Nothing follows it. Whether this section was intentionally left empty or was never completed, there is no documentation of the security trade-offs around downloading and executing precompiled JavaScript engine binaries from external sources.

That gap matters in certain environments. jsvu fetches binaries from engine maintainers' own release pipelines: V8 comes from Chromium infrastructure, SpiderMonkey from Mozilla, JavaScriptCore from WebKit or from the WebKitForWindows project on that platform. No signature verification process is described anywhere in the project's public-facing documentation, and the repository listing does not include a checksum file or a verification guide.

For an individual developer working on a personal machine, the absent section may not be a blocking concern. For a shared CI system or an environment subject to security review, reading the download logic in `cli.js` and the per-engine modules under `engines/` is the practical way to understand what jsvu actually does with those downloads. The last push was on 2026-07-30, the repository is not archived, and the code is under Apache-2.0.

Editorial conclusion

jsvu is the right choice when you write cross-engine test harnesses or check ECMAScript specification behaviour without a build step. It is a poor fit when your team needs a documented security model before allowing downloaded executables. On 32-bit Linux, only V8, V8 debug, SpiderMonkey and QuickJS-ng are available. Before running jsvu in CI, verify that --os matches your runner's actual architecture, since --os=default may misidentify a 32-bit Node process on a 64-bit host. The Security cons section in the README is a heading with no content; check cli.js and the engines/ directory before deploying jsvu in a reviewed environment.

Frequently asked questions

Official sources

1. GoogleChromeLabs/jsvu on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README