From d8b84d1ee05e670564b17486d0c546c98da7af5f Mon Sep 17 00:00:00 2001 From: Brandur Date: Wed, 7 Oct 2026 11:35:31 -0500 Subject: [PATCH] Prepare River JS v0.2.0 Try to get an initial release of the fully functional client out. I've compacted down the changelog to one entry for this, bumped versions, and updated release instructions to something usable today. --- .github/workflows/js.yaml | 2 +- js/CHANGELOG.md | 55 +---------------------- js/README.md | 2 - js/cli/package.json | 8 ++-- js/docs/development.md | 82 +++++++++++++++++----------------- js/driver/pg/package.json | 6 +-- js/driver/prisma/package.json | 6 +-- js/driver/sqlite/package.json | 8 ++-- js/migrate/package.json | 8 ++-- js/package.json | 2 +- js/pnpm-lock.yaml | 26 +++++------ js/test/package.json | 6 +-- js/worker-threads/package.json | 10 ++--- 13 files changed, 83 insertions(+), 138 deletions(-) diff --git a/.github/workflows/js.yaml b/.github/workflows/js.yaml index 8ee1ea607..634a146fe 100644 --- a/.github/workflows/js.yaml +++ b/.github/workflows/js.yaml @@ -13,7 +13,7 @@ on: - "conformance/**" - "js/**" - "riverdriver/**/*.sql" - tags: ["v*"] + tags: ["js/v*"] pull_request: paths: - ".github/actions/setup-js/**" diff --git a/js/CHANGELOG.md b/js/CHANGELOG.md index e47217a3c..8f5903652 100644 --- a/js/CHANGELOG.md +++ b/js/CHANGELOG.md @@ -7,62 +7,11 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ## [Unreleased] -This release turns the insert-only 0.1 client into a complete River -implementation that interoperates with River for Go and Rust in the same -database. It requires Node.js 26 with native `Temporal`. See -[migrating from 0.1](./docs/migrating-from-0.1.md); `riverqueue codemod-0.1` -rewrites the mechanical changes. +## [0.2.0] - 2026-10-07 ### Added -- Workers and a supervised runtime: `Workers`, `client.start()` returning a `RunHandle` (`stop`, `completed`, `await using`), per-queue concurrency, dynamic queues, cooperative cancellation through `AbortSignal`, job timeouts, stuck-job detection with `jobStuckThreshold` (10 seconds by default, like River for Go's `JobStuckThreshold`), graceful and cancelling shutdown, and resilience to transient database failures. -- Like River for Go, a stopping leader resigns and ends maintenance as the stop begins, while its queues drain, and a failed runtime shuts down the same way before `run.completed` rejects. A removed queue's name stays reserved until its jobs finish. -- A client-wide `fetchCooldown` (100 ms by default, like River for Go's `FetchCooldown`) is the claim cooldown of queues that don't set their own, and limits insert notifications like Go's client: on every driver, a client notifies a queue of new jobs at most once per cooldown, whether it inserts them directly, as periodic jobs, or by scheduling them. Retrying a job sends no insert notification. -- `fetchOnlyKnownKinds: true` limits a client's claims to the kinds it has workers for when it starts, like River for Go's `Config.FetchOnlyKnownKinds`, so clients with different workers can share a queue while jobs of other kinds stay available without using an attempt. -- Like River for Go, a client without notifications, whether `pollOnly: true` or on a server without them, checks its running jobs for cancellation requests every `queueControlPollInterval` (two seconds by default), including while a stop drains them, so another client's cancellation reaches it. -- YugabyteDB is supported as a PostgreSQL server, like River for Go: `PgDriver` and `PrismaDriver` detect it, mark unique insertions with a `river:unique_nonce` metadata value in place of `xmax`, and, unless `yb_enable_listen_notify` is on, send no notifications while clients poll as if `pollOnly` were set. On PostgreSQL 18 and later, unique insertions read the conflicting row through `RETURNING OLD`. -- Like River for Go, when a new leader's periodic job enqueuer fails to start three times, the leader resigns that term itself instead of continuing to retry. -- Client options, including `maintenance` and `eventLoopDelay`, queue configuration, in `queues` and in `addQueue` and `updateQueue`, and stop options reject keys River doesn't know, such as a misspelled `pollInterval`, with a `ValidationError`. -- Job definitions with `defineJob`, validated by any Standard Schema library or an explicit decoder on insert and again before work. A definition's `kindAliases` lets its worker also work jobs stored under other kinds, like River for Go's `JobArgsWithKindAliases`, so a kind can be renamed safely. -- Work outcomes `complete`, `snooze`, `discard`, and `cancel`; retry policies per client or, like River for Go's `Worker.NextRetry`, per worker; an error handler, resumable steps, output recording, and transactional completion with `ctx.completeTx`. -- Like River for Go, a handler's `signal` aborts with a `JobAttemptFinishedError` once its attempt finished, so work the handler left running stops. -- Leader election and maintenance matching Go: scheduler, rescuer, job and queue cleaners, PostgreSQL reindexer, and periodic jobs (`periodicJob`) with fixed intervals or custom schedules such as cron. Like Go, maintenance works in batches of 10,000 rows with a timeout on each batch and a random 50 ms to 1 s pause between batches, and a service switches to batches of 1,000 after three timed-out batches in a row. -- `leaderElectionDisabled: true` keeps a client out of leader election, like River for Go's `Config.LeaderElectionDisabled`: it works jobs from its queues while other eligible clients in the same database and schema handle scheduling, retries, periodic jobs, rescue, and cleanup. Such a client rejects `periodicJobs` and changes to `client.periodicJobs` with a `ConfigurationError`. -- `cron()`, a periodic schedule that parses cron expressions exactly like River for Go (robfig/cron's `ParseStandard`, including descriptors, `@every`, and `CRON_TZ=` prefixes) and fires at the same times. Expressions without a `CRON_TZ=` prefix or `timeZone` option are evaluated in the process's local time zone, as in Go; pin a zone in mixed-language fleets. -- Job and queue queries and controls under `client.jobs` and `client.queues`, with opaque keyset pagination. Job list cursors use River for Go's `JobListCursor` text format, so page tokens pass freely between River for Go, Rust, and JavaScript. Like Go, ordering by `time` sorts every listed job by the first listed state's time field (`scheduledAt` without a state filter), with null times last ascending and first descending, and cursors carry that field's value. -- Hooks, work and insert middleware, plugins, bounded event subscriptions, `diagnostics_channel` publishing, and pino-compatible logging. -- `Workers.add` also takes a `WorkHandlerFactory`, whose `createWorkHandler` builds the handler from the definition it's registered with, so an integration's worker is registered as `workers.add(definition, integrationWorker(options))`. -- `@riverqueue/driver-sqlite`, a complete runtime on Node's built-in `node:sqlite`. Like River for Go, River runs on a private connection to the application's database file, in WAL mode, so application statements never join River's transactions. - - Pass an application handle with a transaction open as `{ tx }` to insert jobs with application rows. `transaction(database, callback)` begins one with `BEGIN IMMEDIATE`, retrying asynchronously while another connection holds the write lock. - - `SqliteDriver.memory()` and `driver.connect()` share an in-memory database, and `driver.close()` closes River's connection. - - Once River's own transaction holds the write lock, a River call without `{ tx }` from inside it, such as from insert middleware after `next()`, fails at once with a `TransactionScopeError` instead of waiting for it forever. - - On SQLite, insert middleware and hooks must not await I/O after `next()`, while River holds the write lock. When River's transaction is still open at the event loop's next turn, River rolls it back and fails the insertion with a `TransactionScopeError` whose `reason` is `"event_loop_turn"`. The check finds most mistakes, including all slow I/O and every insertion started from an I/O callback such as an HTTP handler, but it isn't deterministic for fast local I/O awaited by an insertion started from a timer or `setImmediate` callback. -- `@riverqueue/migrate` with River's canonical PostgreSQL and SQLite migrations, and `@riverqueue/cli` with migration commands, `bench`, and the 0.1 codemod. -- River's migration 8: on SQLite it rebuilds `river_job` with an `AUTOINCREMENT` key so a deleted job's ID is never reused, and, like River for Go, refuses to run while an extension's `river_job_sequence`, `river_job_workflow_scheduling`, or `river_workflow` schema exists; on PostgreSQL it changes nothing. -- `@riverqueue/worker-threads` for CPU-bound handlers, and `@riverqueue/test` with test clients, insertion assertions, and `workOnce`. A worker-thread handler that still ignores its abort after the client's `jobStuckThreshold` has its thread terminated; when the abort came from a stopping client, it fails with a `JobAbortedError`, so its attempt counts and a job that hangs on every stop doesn't retry forever. - -### Changed - -- Job IDs are `bigint` and timestamps are `Temporal.Instant`, so no database value is rounded. Job args and metadata use an exact JSON domain that preserves numbers JavaScript cannot represent. -- Argument classes (`JobArgs`, `JobArgsObject`) and `InsertManyParams` are replaced by job definitions and plain `{ job, args, options }` batch items; insert results report `status: "inserted" | "duplicate"`. -- Insert options use `unique` (was `uniqueOpts`) with duration values such as `byPeriod: { seconds: 60 }`, add `delay`, and accept `Date` or `Temporal.Instant` for `scheduledAt`. Every duration option takes a `Temporal.Duration` or duration-like object. -- Like River for Go, `insertMany` rejects a batch in which a unique key appears more than once among jobs whose state the key covers with a `ValidationError`, before writing any of it. 0.1 inserted the first such job and reported the rest as duplicates of it. -- Like River for Go, `unique.excludeKind` requires `byArgs`, `byQueue`, or `byPeriod` and is otherwise rejected with a `ValidationError`, since the unique key would be the same for every job. -- `ClientOpts`, `InsertOpts`, and `UniqueOpts` are renamed `ClientOptions`, `InsertOptions`, and `UniqueOptions`; `riverqueue codemod-0.1` imports them under their 0.1 names. -- The PostgreSQL schema is configured on `PgDriver`, which accepts any `node-postgres` client as a transaction. `@riverqueue/driver-prisma` clients are typed as insert-only. -- Errors River throws all extend `RiverError` with a stable `code`. -- River for Go's `InsertManyFast` has no counterpart yet; use `insertMany`, which returns one result per row, reports a unique conflict as `status: "duplicate"` rather than skipping the row (SQLite) or failing the batch (PostgreSQL), and runs insert middleware and hooks. -- Like River for Go, a job inserted without a schedule takes its creation and scheduled times from the database's clock, so a producer never waits out a difference between the application's clock and the database's. -- The packages ship as ESM only; `require()` works through Node 26's `require(esm)`. -- Like River for Go, an operation given a caller's transaction as `{ tx }` runs directly in it and opens no savepoint or nested transaction, on every driver, including transactional completion with `completeTx`. When the operation fails after writing, such as from insert middleware or a hook that throws after the write, its writes stay in the caller's transaction, which the caller rolls back; on PostgreSQL a database error aborts that transaction. Validation still fails before anything is written. An application that needs to recover and continue the transaction can wrap the call in a savepoint of its own. -- Like River for Go, `insert` and `insertMany` without `{ tx }` run argument validation, insert middleware, `beforeInsert` and `afterInsert` hooks, and the write in one transaction River owns, so an error thrown by middleware after `next()` returns or by an `afterInsert` hook rolls the jobs back. -- A `PgDriver` constructed from a single `node-postgres` client, not a pool, rejects insertions without `{ tx }` with a `ConfigurationError`, like River for Go's drivers without a pool: River needs a connection of its own to begin a transaction. Pass `{ tx }` or construct the driver with a `Pool`. `PrismaDriver` runs such insertions in a Prisma interactive transaction, so its client must be a root `PrismaClient` with `$transaction`; its `transactionOptions` sets that transaction's `maxWait` and `timeout`. -- Drivers are opaque: `PgDriver`, `SqliteDriver`, and `PrismaDriver` expose only their construction, plus `SqliteDriver.memory()`, `connect()`, and `close()`. River's operations, such as 0.1's `jobInsert` and `jobInsertMany`, aren't callable on them, and `PgDriver` no longer exposes its `pool` or `schema`, nor `SqliteDriver` its `database`: keep your own reference to the connection. `createMigrator(driver)` still migrates the driver's connection and schema. `new Client()` accepts only a River driver, not any object with insertion methods; test clients come from `@riverqueue/test`. -- Updated the Prisma example and `@riverqueue/driver-prisma` usage documentation for Prisma 7. The example now uses `@prisma/adapter-pg`, `prisma.config.ts`, and an explicitly generated ESM TypeScript client; its build automatically runs `prisma generate` before compilation. Prisma 7 requires Node.js `^20.19`, `^22.12`, or `>=24`. [PR #31](https://github.com/riverqueue/riverqueue-js/pull/31). - -### Fixed - -- A unique insertion with `excludeKind` that's skipped as a duplicate of a job of another kind no longer changes that job's kind to its own, which made workers of the other kind run it with the first job's arguments. The existing job keeps its kind, like River for Go. +- JavaScript now implements full River client support for PostgreSQL and SQLite, interoperating with Go and Rust in the same database. Includes workers, graceful stopping and cancellation, leader election and maintenance, periodic and resumable jobs, job and queue management, hooks, middleware, events, migrations, CLI tooling, worker threads, and test helpers. Requires Node.js 26 with native `Temporal`; job IDs are `bigint` and timestamps are `Temporal.Instant`. This replaces the insert-only 0.1 API; see [migrating from 0.1](./docs/migrating-from-0.1.md) and `riverqueue codemod-0.1` for upgrades. [PR #1443](https://github.com/riverqueue/river/pull/1443). ## [0.1.0] - 2026-06-01 diff --git a/js/README.md b/js/README.md index 4a474bdc3..84f5ae806 100644 --- a/js/README.md +++ b/js/README.md @@ -5,8 +5,6 @@ This implementation runs on Node.js and shares River's database protocol with River for Go and Rust, so services in all three languages can insert and work the same jobs in the same database. -It is currently an alpha and is not published from this branch. - ## Requirements - **Node.js 26 with native `Temporal`.** River uses `Temporal.Instant` for diff --git a/js/cli/package.json b/js/cli/package.json index ad860ad4e..2b61dd6de 100644 --- a/js/cli/package.json +++ b/js/cli/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/cli", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Command-line migrations, benchmarks, and upgrade codemods for River TypeScript.", "type": "module", "sideEffects": [ @@ -49,10 +49,10 @@ "provenance": true }, "dependencies": { - "@riverqueue/driver-pg": "workspace:0.50.0-alpha.1", - "@riverqueue/migrate": "workspace:0.50.0-alpha.1", + "@riverqueue/driver-pg": "workspace:0.2.0", + "@riverqueue/migrate": "workspace:0.2.0", "pg": "^8.22.0", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "peerDependencies": { "@types/node": ">=26", diff --git a/js/docs/development.md b/js/docs/development.md index e0e99de37..b086d9c77 100644 --- a/js/docs/development.md +++ b/js/docs/development.md @@ -8,7 +8,7 @@ River's top-level `make` targets (`make lint/js`, `make test/js`, and so on), which delegate to `pnpm -C js`. Use an official Node.js 26 build, which includes native Temporal. The -repository's `.node-version` selects Node 26 for version managers such as fnm, +workspace's `.node-version` selects Node 26 for version managers such as fnm, nvm (`nvm use $(cat .node-version)`), and `actions/setup-node`. Some Node.js builds compiled from source, including some distribution and Homebrew packages, lack Temporal, and most unit tests then fail with @@ -189,7 +189,7 @@ to benchmark against a disposable database: River's `.github/workflows/js.yaml` runs on pull requests and pushes to `master` that change `js/`, River's migrations or SQL, or the workflow itself, -and on release tags. Each job installs the official Node.js build from +and on `js/v*` release tags. Each job installs the official Node.js build from `js/.node-version` and fails unless `typeof Temporal` is `object`. The jobs cover build, both type-check lanes, generated migrations (compared with River's sources), API reports, TypeDoc, README snippets, the 0.1 fixture, lint, @@ -210,54 +210,52 @@ order are Rust-only because JavaScript objects cannot preserve them. ## Preparing a release -The eight publishable packages are the root `riverqueue` package, the three -drivers under `driver/*`, and `migrate`, `worker-threads`, `test`, and `cli`. -They share one release version. Examples are private and stay at `0.0.0`. -The core and PostgreSQL/Prisma drivers were already released as 0.1.0; this -checklist prepares a release of the expanded workspace. +Run this section's commands from the repository root. The eight publishable packages are `js/package.json` (`riverqueue`), the three drivers under `js/driver/*`, and `js/{migrate,worker-threads,test,cli}`. They share one version, independently of Go and Rust. Examples are private and stay at `0.0.0`. `VERSION` has no leading `v`; JavaScript Git tags use `js/vX.Y.Z`. -1. Fetch changes to the repo and choose the target npm version, including a - prerelease suffix when applicable. Do not infer it from the latest - repository tag: this repository also contains Go and Rust releases. +1. Fetch changes and tags, choose the next JavaScript version (including a prerelease suffix when applicable), and create a release branch: ```shell git checkout master && git pull --rebase + git fetch --tags export VERSION=0.x.y - git checkout -b $USER-$VERSION + git checkout -b "$USER-js-$VERSION" ``` -2. Update every publishable `package.json` to the same version, including the - exact `workspace:` versions of first-party `dependencies`, - `peerDependencies`, and `devDependencies`, then regenerate `pnpm-lock.yaml`. - Libraries take `riverqueue` as an exact peer so a mismatched pair fails at - install time instead of loading two copies; only the self-contained CLI - depends on it directly. Do not change the private example package - versions or their `workspace:*` references, or the pinned historical - `fixtures/migration-0.1` files. After editing the manifests, update the - lockfile: +2. Set every publishable `package.json` version to `$VERSION` and update its exact `workspace:` references in `dependencies`, `peerDependencies`, and `devDependencies`. Libraries take `riverqueue` as an exact peer; the CLI depends on it directly. Keep private example versions and their `workspace:*` references, and the historical `js/fixtures/migration-0.1` files. Refresh the lockfile: ```shell - pnpm install --lockfile-only + pnpm -C js install --lockfile-only ``` -3. Update `CHANGELOG.md` by moving the release notes from `Unreleased` into a - heading for the new version. - -4. Open a PR with the version, lockfile, and changelog changes, and let the - [JavaScript CI workflow](#continuous-integration) validate them. It runs - the build, tests, lint, package checks, and Node/PostgreSQL matrices. - Local reruns are optional and useful for debugging CI failures. - -5. After merge, release from a `master` commit with passing JavaScript CI - that includes the release's version and lockfile changes. - Publication remains a separate, explicitly authorized operation after merge. - -There is currently no npm publication workflow in this repository: -`.github/workflows/js.yaml` runs checks on `v*` tags but does not publish -packages. All eight packages set `publishConfig.provenance: true`, so -publication needs a supported CI environment configured for -[npm provenance](https://docs.npmjs.com/generating-provenance-statements/) -(including `id-token: write` on GitHub Actions). A publication workflow and -release-tag convention still need to be established. For a prerelease, use an -explicit [npm distribution tag](https://pnpm.io/10.x/cli/publish#--tag-tag), -such as `next`; `pnpm publish` defaults to `latest`. +3. Move `js/CHANGELOG.md` entries from `Unreleased` into a `[$VERSION] - YYYY-MM-DD` section, and update any versioned README examples. + +4. Open a PR with the manifests, `js/pnpm-lock.yaml`, changelog, and README changes. Keep [JavaScript CI](#continuous-integration) enabled and merge after checks pass. To verify the package archives locally: + + ```shell + make check/js/package + ``` + +5. After merge, pull the release commit into a clean checkout, confirm its version, and push only its JavaScript tag: + + ```shell + git checkout master && git pull --rebase + test "$(node -p 'require("./js/package.json").version')" = "$VERSION" + git tag "js/v$VERSION" -m "release js/v$VERSION" + git push origin "js/v$VERSION" + ``` + +6. Publish locally from the clean `master` checkout tagged above after its JavaScript checks pass. Use official Node.js 26 and the pinned pnpm version, and log in with an npm account that can publish all eight packages. A publication workflow is optional. Disable [provenance](https://docs.npmjs.com/generating-provenance-statements/) for local publication with `--provenance=false`, overriding the packages' `publishConfig.provenance: true`: + + ```shell + test "$(git rev-parse HEAD)" = "$(git rev-parse "js/v$VERSION^{commit}")" + npm login + pnpm -C js install --frozen-lockfile + pnpm -C js run build:all + for package in js js/migrate js/driver/pg js/driver/prisma js/driver/sqlite js/worker-threads js/test js/cli; do + pnpm -C "$package" publish --access public --tag latest --provenance=false || break + done + ``` + + Complete npm's authentication prompts as needed. Publish packages individually because pnpm 10.22.0's recursive publication does not forward `--provenance=false` to npm. The loop publishes dependencies first and stops on failure; after a partial publication, remove the already-published packages from the loop before rerunning it. For a prerelease, use `--tag next` instead of `--tag latest`. + +7. Once all eight packages are published, create a [GitHub release](https://github.com/riverqueue/river/releases/new) for `js/v$VERSION` and copy the version's `js/CHANGELOG.md` notes into its body. Mark alpha, beta, and RC versions as prereleases. diff --git a/js/driver/pg/package.json b/js/driver/pg/package.json index abdb84e78..5927888d9 100644 --- a/js/driver/pg/package.json +++ b/js/driver/pg/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/driver-pg", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Complete node-postgres backend for River's TypeScript runtime.", "type": "module", "sideEffects": false, @@ -48,7 +48,7 @@ "peerDependencies": { "@types/pg": ">=8", "pg": ">=8.0.0", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "peerDependenciesMeta": { "@types/pg": { @@ -58,7 +58,7 @@ "devDependencies": { "@types/pg": "^8.20.0", "pg": "^8.22.0", - "riverqueue": "workspace:0.50.0-alpha.1", + "riverqueue": "workspace:0.2.0", "typescript": "^6.0.3" }, "keywords": [ diff --git a/js/driver/prisma/package.json b/js/driver/prisma/package.json index 0c66a1f50..5d1684ef0 100644 --- a/js/driver/prisma/package.json +++ b/js/driver/prisma/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/driver-prisma", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Prisma driver for the riverqueue TypeScript client.", "type": "module", "sideEffects": false, @@ -44,13 +44,13 @@ }, "peerDependencies": { "@prisma/client": ">=5.0.0", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "devDependencies": { "@prisma/adapter-pg": "7.9.1", "@prisma/client": "7.9.1", "prisma": "7.9.1", - "riverqueue": "workspace:0.50.0-alpha.1", + "riverqueue": "workspace:0.2.0", "typescript": "^6.0.3" }, "keywords": [ diff --git a/js/driver/sqlite/package.json b/js/driver/sqlite/package.json index 67b5f0b4f..1a88031b5 100644 --- a/js/driver/sqlite/package.json +++ b/js/driver/sqlite/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/driver-sqlite", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "First-party node:sqlite backend for River.", "type": "module", "sideEffects": false, @@ -46,7 +46,7 @@ }, "peerDependencies": { "@types/node": ">=26", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "peerDependenciesMeta": { "@types/node": { @@ -54,9 +54,9 @@ } }, "devDependencies": { - "@riverqueue/migrate": "workspace:0.50.0-alpha.1", + "@riverqueue/migrate": "workspace:0.2.0", "@types/node": "^26.1.1", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "keywords": [ "river", diff --git a/js/migrate/package.json b/js/migrate/package.json index 30fd0f8eb..3bf4090a5 100644 --- a/js/migrate/package.json +++ b/js/migrate/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/migrate", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Canonical River database migrations for JavaScript and TypeScript.", "type": "module", "sideEffects": false, @@ -46,7 +46,7 @@ }, "peerDependencies": { "@types/node": ">=26", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "peerDependenciesMeta": { "@types/node": { @@ -54,10 +54,10 @@ } }, "devDependencies": { - "@riverqueue/driver-pg": "workspace:0.50.0-alpha.1", + "@riverqueue/driver-pg": "workspace:0.2.0", "@types/node": "^26.1.1", "pg": "^8.22.0", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "keywords": [ "river", diff --git a/js/package.json b/js/package.json index 9bd48cf84..1b8ef963a 100644 --- a/js/package.json +++ b/js/package.json @@ -1,6 +1,6 @@ { "name": "riverqueue", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "TypeScript implementation of River, a fast and reliable background job system.", "type": "module", "sideEffects": false, diff --git a/js/pnpm-lock.yaml b/js/pnpm-lock.yaml index 1c841c76d..fa5c8f39c 100644 --- a/js/pnpm-lock.yaml +++ b/js/pnpm-lock.yaml @@ -85,16 +85,16 @@ importers: cli: dependencies: '@riverqueue/driver-pg': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../driver/pg '@riverqueue/migrate': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../migrate pg: specifier: ^8.22.0 version: 8.22.0 riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:.. devDependencies: '@types/node': @@ -120,7 +120,7 @@ importers: specifier: ^8.22.0 version: 8.22.0 riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../.. typescript: specifier: ^6.0.3 @@ -138,7 +138,7 @@ importers: specifier: 7.9.1 version: 7.9.1(@types/node@26.1.1)(@types/react@19.2.18)(magicast@0.5.5)(react-dom@19.2.8(react@19.2.8))(react@19.2.8)(typescript@6.0.3) riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../.. typescript: specifier: ^6.0.3 @@ -147,13 +147,13 @@ importers: driver/sqlite: devDependencies: '@riverqueue/migrate': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../../migrate '@types/node': specifier: ^26.1.1 version: 26.1.1 riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../.. examples/graceful-shutdown: @@ -356,7 +356,7 @@ importers: migrate: devDependencies: '@riverqueue/driver-pg': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../driver/pg '@types/node': specifier: ^26.1.1 @@ -365,28 +365,28 @@ importers: specifier: ^8.22.0 version: 8.22.0 riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:.. test: devDependencies: riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:.. worker-threads: devDependencies: '@riverqueue/driver-sqlite': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../driver/sqlite '@riverqueue/migrate': - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:../migrate '@types/node': specifier: ^26.1.1 version: 26.1.1 riverqueue: - specifier: workspace:0.50.0-alpha.1 + specifier: workspace:0.2.0 version: link:.. packages: diff --git a/js/test/package.json b/js/test/package.json index bb2f0b273..9c8c95649 100644 --- a/js/test/package.json +++ b/js/test/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/test", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Typed test helpers for River jobs, workers, and clients.", "type": "module", "sideEffects": false, @@ -44,10 +44,10 @@ "provenance": true }, "peerDependencies": { - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "devDependencies": { - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "keywords": [ "river", diff --git a/js/worker-threads/package.json b/js/worker-threads/package.json index a9df6c897..a86c99865 100644 --- a/js/worker-threads/package.json +++ b/js/worker-threads/package.json @@ -1,6 +1,6 @@ { "name": "@riverqueue/worker-threads", - "version": "0.50.0-alpha.1", + "version": "0.2.0", "description": "Optional bounded worker-thread executor for River TypeScript.", "type": "module", "sideEffects": [ @@ -48,7 +48,7 @@ }, "peerDependencies": { "@types/node": ">=26", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "peerDependenciesMeta": { "@types/node": { @@ -56,10 +56,10 @@ } }, "devDependencies": { - "@riverqueue/driver-sqlite": "workspace:0.50.0-alpha.1", - "@riverqueue/migrate": "workspace:0.50.0-alpha.1", + "@riverqueue/driver-sqlite": "workspace:0.2.0", + "@riverqueue/migrate": "workspace:0.2.0", "@types/node": "^26.1.1", - "riverqueue": "workspace:0.50.0-alpha.1" + "riverqueue": "workspace:0.2.0" }, "keywords": [ "river",