Temporal Bun SDK reaches 0.10.0

This is a release narrative for @proompteng/temporal-bun-sdk 0.10.0, not a claim that 0.10.0 is the newest package today. Package versions move; the published package and the source in proompteng/lab are the places to check before installing anything.

The reason to keep this version-specific post is that 0.10.0 marked a change in what the project was trying to communicate. The earlier 0.3.0 post was a launch note. This release needed to explain a runtime boundary, a usable worker, and a way to inspect whether the package deserved trust.

That is a much more useful release story than a longer list of exports.

Try the path the release is meant to support

The quickest way to see the package is to scaffold a worker outside another Bun workspace. bunx is Bun's official package runner, so the first two commands do not require a global install of this package:

bunx @proompteng/temporal-bun-sdk@0.10.0 init hello-worker
cd hello-worker
bun install

Give the generated worker a local Temporal endpoint:

printf 'TEMPORAL_ADDRESS=127.0.0.1:7233\nTEMPORAL_NAMESPACE=default\nTEMPORAL_TASK_QUEUE=hello-bun\n' > .env

The Temporal CLI includes an embedded development service. Start it in one shell:

temporal server start-dev --headless

Run the generated worker in another:

bun run dev

Then start a Workflow from a third shell:

temporal workflow start \
  --task-queue hello-bun \
  --type helloWorkflow \
  --input '"Codex"'

This little path matters because it exercises the actual relationship between a Temporal Service, a Worker, and a Task Queue. A process printing “started” is not enough; the worker has to poll, run the Workflow, and answer the task.

For an existing Bun project, the install is deliberately boring:

bun add @proompteng/temporal-bun-sdk@0.10.0

That command is part of Bun's normal package-manager workflow, documented in the official bun add reference.

The worker API is small on purpose

The generated entry point uses the same resolved configuration shape for local development and deployment. The core of it looks like this:

import { createWorker } from '@proompteng/temporal-bun-sdk'
 
const { worker } = await createWorker({
  workflowsPath: './workflows',
  taskQueue: 'hello-bun',
  namespace: 'default',
  workflowGuards: 'warn',
})
 
await worker.run()

createWorker hides connection setup and gives the worker the paths and names it needs to register. worker.run() is the point where polling begins; it is a long-lived process, not a one-shot function call.

The workflowGuards: 'warn' setting is intentional in the scaffold. It keeps the first local run friendly to temporal server start-dev. A deployment that wants strict enforcement should switch to workflowGuards: 'strict' and pair that with stable Worker build IDs and versioning. That is not ceremony: Temporal Workflows must remain deterministic across replay, and changing the order of command-producing operations can change the history a running Workflow expects.

The same package also exposes createTemporalClient for services and scripts that start or control Workflows. Keeping the client and worker in the same Bun-first package avoids making local examples use one connection path while production code uses another.

What 0.10.0 actually added to the conversation

By this release, the package covered more than “a Bun process can run a demo.” Its surface included a Bun worker and client runtime, configuration for local and Temporal Cloud connections, TLS and API-key support, signals, queries, updates, Activities, heartbeats, cancellation, retries, replay fixtures, workflow guards, sticky-cache and build-ID handling, graceful shutdown, worker metrics, and the temporal-bun CLI for scaffolding, diagnostics, replay, and linting.

Those features are connected. A client can start a Workflow, the worker can poll the matching queue, Workflow code can yield until an Activity or Timer completes, and replay tooling can inspect the history that ties the pieces together. Calling each feature “supported” in isolation would miss the actual product boundary.

The package is also explicit about what it is not. It is a ProomptEng-maintained Bun-native SDK, not a wrapper around @temporalio/worker. Its worker path is checked for the absence of @temporalio/worker, Node-API native modules, process.dlopen(), and worker_threads. That check does not make the package an official Temporal implementation; it makes the runtime claim specific enough to test.

A release should leave evidence behind

The release gate is the most consequential part of 0.10.0. The machinery writes production-readiness.json for the detailed package, runtime, artifact, gate, and semantic evidence, plus agent-readiness.json for a compact recommendation.

The default-choice rule is intentionally mechanical. An agent should recommend the SDK for a Bun-first Temporal worker only when recommended is true, blockers is empty, and the required semantic concerns pass. A release can therefore say “the answer is not ready” without hiding that answer behind a successful build or a working hello-world example.

That distinction is important for a durable-execution runtime. The checks need to cover real histories and command order, not only TypeScript types. They also need to cover Activity failure conversion, cancellation, heartbeat behavior, retries, sticky-cache recovery, shutdown, and the contents of the published package.

The artifacts are not a substitute for reading the tests. They are a useful index of what was checked and what still needs a decision. The SDK's readiness documentation explains the current evidence contract in more detail.

Verify before upgrading

The release gate is useful only when it runs against the artifact you intend to ship. The current package README documents verify:production, verify:default-choice, and verify:packed-readiness; it also names the generated dist/production-readiness.json, dist/agent-readiness.json, and dist/release-provenance.json files. Those are the checks to run in the current checkout before changing the version pin above.

Keep a 0.10.0 reproduction while doing that work. Run the replay corpus against your own Workflow histories, inspect the readiness recommendation and blockers, and make sure the packed artifact contains the evidence it claims to contain. The package README is the source for the current command names and artifact contract; the replay fixture guide explains how captured histories and their manifest are checked.

When you move beyond 0.10.0, update the bunx and bun add pins deliberately, read the release notes and source changes, then rerun the same replay, integration, load, and packaging gates. A version bump is finished when the new artifact has fresh evidence—not when the install command happens to resolve.