Hybrid Compute

Appearance

1.0 release notes October 2026 ​

Hybrid Compute 1.0: run each task where it fits

All four packages go to 1.0.0 together: core, local, remote and worker.

These notes cover everything that changed between the 0.x releases and 1.0. For the code changes, step by step, see the upgrading guide. Questions? See getting help.

Overview ​

1.0 is a promise more than a feature: from 1.0 on, the public API only breaks in a major release. Every function, option, error type and message format you use today keeps working through every 1.x release.

To make that promise, each package had an API review in October 2026, with the findings and decisions recorded in its issue. The reviews didn't add much surface; they made what was there dependable:

  • Nothing fails silently. Bad options and arguments throw straight away, with a message that says what to change. No task waits forever: remote tasks time out, crashed workers reject their tasks, and every task can be cancelled.
  • One error type per backend. NoBackendError when nothing can run a task, RemoteTaskError and WorkerTaskError when a task fails, each with the task name and the details, so you can match on the type instead of the message.
  • Built for bundlers and modern runtimes. ES2022 ES modules with an exports map, source maps that resolve, and a createWorker option that Vite and webpack understand.

If you're on 0.38 or later, most of the work is behind you. If you're on 0.37 or older, the upgrading guide has a checklist.

What's new ​

Cancelling any task ​

runTask takes an AbortSignal, on every backend:

ts
const controller = new AbortController();
const result = compute.runTask('resize', image, 'auto', {
  signal: controller.signal
});

controller.abort(); // result rejects with the signal's reason

local tasks and exposeTasks workers get the signal as run(input, { signal }), so long-running work can stop early. remote aborts the request.

@hybrid-compute/core ​

  • Validation: the backends passed to createHybridCompute, and the task name and strategy passed to runTask, are checked, with a TypeError or RangeError for mistakes.
  • NoBackendError when no backend can run a task, with its taskName and strategy.
  • canRun for every strategy: an explicit 'local', 'worker' or 'remote' now checks the backend can run the task, as auto always did.
  • No runtime dependencies.

@hybrid-compute/local ​

  • registerTask checks the task and refuses a name that's already registered; unregisterTask(name) removes one.
  • A task's run can return a plain value or a Promise, and gets the caller's signal.

@hybrid-compute/remote ​

  • canRunTasks is required: list the tasks the server runs, or pass '*'. Before, leaving it out sent any task to the server.
  • RemoteTaskError for every failure, with the server's error as detail, the HTTP status and the cause.
  • A 30 second timeout by default, set with timeout.
  • A WebSocket that connects when needed: on the first task, again after it closes, with close() to end it.
  • headers for the fetch transport, as an object or a function, for example to send a fresh token.
  • Typed messages: RemoteTaskRequestInterface and RemoteTaskResponseInterface describe what your server receives and sends.

@hybrid-compute/worker ​

  • An options object:createThreadedCompute({ createWorker, canRunTasks, timeout }), or url for a script served without a bundler.
  • createWorker, so Vite and webpack build the worker script. Passing a bare new URL(...) didn't work with either.
  • exposeTasks writes the worker script for you: tasks by name, errors as replies, and cancelling.
  • WorkerTaskError for every failure, and no more hanging tasks: a crash or a script that doesn't load rejects every waiting task, and the next task starts a new worker.
  • close() terminates the worker.

WebAssembly ​

WebAssembly needs no backend of its own: a module's exports are functions, so they run as local tasks or in a worker with exposeTasks. The new WebAssembly guide shows both with a Rust example.

Trust and quality ​

  • Published with provenance from GitHub Actions with npm trusted publishing, with a CycloneDX SBOM attached to every GitHub release. Check what you installed with npm audit signatures.
  • Every tarball is checked before it's published: packed, linted with publint and @arethetypeswrong/cli, installed and imported.
  • Tests at 99% of lines or more in every package, enforced in CI, with property-based tests for dispatch, the local registry and message round-trips, and real threads and a real HTTP and WebSocket server instead of mocks.
  • The OpenSSF Best Practices passing badge, and most of silver.

What's not changing ​

  • The four packages and what they're for. core dispatches, local, worker and remote run tasks.
  • The strategies: 'auto', 'local', 'worker' and 'remote', and the auto order: worker, then local, then remote.
  • The message format. { task, input } out, { result } or { error } back, with an id on both for workers and remote WebSockets.
  • Node.js 22 or later, as before.

Deprecated ​

Nothing. 1.0 is the first release with a deprecation policy: from now on, deprecated APIs keep working through one full major. See deprecations.

Removed ​

Nothing that was documented. The positional createThreadedCompute(url, taskNames) and an optional canRunTasks for remote changed shape during 0.x; see the upgrading guide.

FAQ ​

What do I get from 1.0? ​

Stability. Within 1.x, npm update never needs a change to your code, and the security policy supports 1.x as a whole.

Do I need to upgrade right away? ​

0.x gets no more releases now that 1.0 is out, including security fixes. If you're on 0.38 or later, upgrading is mostly bumping the versions.

How big is the upgrade? ​

From 0.38 or later: update the versions, and check your error handling matches on the new error types. From 0.37 or older: about one change per backend you use, listed in the upgrading checklist.

What about Node.js worker threads? ​

The worker backend uses Web Workers, so it runs in browsers, Deno and Bun. Support for Node.js worker_threads is planned after 1.0, in #127. Where there are no Web Workers, canRun is false, so auto uses another backend.

Getting help ​

  • Questions and ideas: open a discussion or issue.
  • A bug in 1.0: open an issue with the package version and a small example.
  • A security problem: report it privately, as the security policy describes.