Effect 4.x for TypeScript: an LTS release with dated support, tiered API stability and a strict compiler floor

One library covers errors, dependencies, concurrency and validation

Effect positions itself as the layer that handles the hard problems of a TypeScript application at scale. The areas it names are typed errors, dependency injection, structured concurrency, scheduling, tracing, and unified schema validation. Rather than assembling a separate library for each of those concerns, a project built on Effect gets them from one core package, effect, installed with:

npm install effect

The trade is breadth for commitment. Because these concerns share one model, adopting Effect for error handling means working with its approach to dependencies and concurrency as well, and the rest of this piece is about what you sign up for when you do: the support terms, the API stability rules, the compiler and runtime floor, and the package layout. The project's own website at effect.website holds the documentation and guides, and the API reference for the core package lives under the v4 docs.

Effect 4.x carries a dated LTS window

Effect 4.x is declared a long-term support release, and the guarantees are specific. The 4.x line gets at least three years of support, including bug and security fixes. When the next major version ships, 4.x keeps receiving bug fixes for one more year and security fixes for two more years.

For a team planning a system that has to run for years, this is the most concrete reason to pick 4.x over an older line. It also sets a clock: once Effect 5 is released, you have a year before bug fixes stop and two years before security fixes stop, so a migration should be budgeted inside that window rather than discovered at the end of it. The current release is [email protected], published on 2026-11-02, and the last push to main was the same day.

Unstable and experimental APIs can break in minor and patch releases

The LTS promise does not cover every export equally. Stable APIs reserve breaking changes for major releases. APIs marked unstable may change in minor releases, and APIs marked experimental may change in patch releases.

The consequence is practical. If your code touches only stable APIs, a caret range on effect is safe for the life of 4.x. If it uses anything unstable, a minor bump such as 4.1 to 4.2 can require code changes. If it uses anything experimental, even a patch bump such as 4.1.2 to 4.1.3 can break the build. Teams that rely on experimental pieces should pin exact versions and read release notes before every upgrade, and should know which of their imports fall into which tier before they commit to an upgrade policy.

Effect 3 lives on its own branch and moving off it takes a migration

Effect 3 is not abandoned in place; its source code moved to the v3 branch of the repository, and issues and pull requests meant for Effect 3 should target that branch rather than main.

Upgrading from 3.x to 4.x is a migration, not a version bump. The repository carries a MIGRATION.md guide and a migration/ directory, and its package.json defines a codemod script that runs scripts/codemod.mjs. How much of a given codebase the codemod handles is not something to assume; budget time for reading the guide and fixing what it does not cover, especially if the 3.x code leaned on APIs whose shape changed.

TypeScript 5.9, strict mode and Node.js 22.19 are hard requirements

Effect sets a firm floor. TypeScript 5.9 or newer is required, and TypeScript 7 is recommended for the best performance and for compatibility with Effect's TypeScript tooling, which lives in the separate Effect-TS/tsgo project. The repository itself runs its type checks through effect-tsgo, with plain tsc kept as a separate check-tsc script.

The strict flag must be enabled in tsconfig.json. That requirement can block an existing codebase: a project that compiles today only because strict is off cannot drop Effect into one module and leave the rest alone, since the flag applies to the whole compilation. Expect to fix strict-mode errors across the project first.

On the runtime side, Node.js 22.19 or newer is the general minimum for running Effect on Node.js. Services pinned to an older Node release need a runtime upgrade before they can adopt 4.x.

Integration packages ship in lockstep with the core

The repository is a monorepo: the core effect package plus integration packages, all released together with synchronized versions. The 4.1.2 release went out as [email protected] alongside @effect/[email protected] and @effect/[email protected] on the same day.

Platform services come as @effect/platform-browser, @effect/platform-bun, @effect/platform-deno and @effect/platform-node, with @effect/platform-node-shared for Node.js-compatible runtimes. SQL clients cover ClickHouse, Cloudflare D1, libSQL, Microsoft SQL Server, MySQL through mysql2, PostgreSQL, PGlite, SQLite via bun:sqlite, Cloudflare Durable Objects SQLite, and SQLite on Node, among others.

Synchronized versioning makes the rule simple: keep every @effect package at the same version as effect. Upgrading the core without the integrations, or the reverse, leaves you running a combination that was never released together.

Production support is still being shaped outside the repository

Community help runs through Discord, GitHub Issues and the effect.website community hub, and the maintainers invite teams to introduce themselves there or by email at [email protected]. For organizations that need more, the picture is less settled. The maintainers say they are exploring how to better support teams running Effect in production, which means there is no defined production support offering from the core team today. Commercial support, implementation, consulting, team extension and training come from third-party adoption partners listed on the website.

For teams whose procurement requires a support contract, that means the contract will be with a partner, not with the Effect maintainers. The repository also ships an LLMS.md file generated from ai-docs/ by an ai-docgen script, intended for AI coding tools that read project documentation.

Editorial conclusion

Effect 4.x suits TypeScript teams that want typed errors, dependency injection, concurrency, tracing and schema validation from one library and value a written support window measured in years. It is a harder sell for codebases that cannot turn on strict mode, run Node.js older than 22.19, or are still on Effect 3 without time to migrate. Before adopting it, check which of the APIs you plan to use are marked unstable or experimental, and keep every @effect package on the same version as the core.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes