{"slug": "effect-4-0-the-first-week", "title": "Effect 4.0: The First Week", "summary": "Effect-TS shipped Effect 4.0.1 on October 5 and 4.0.2 today, two patch releases that fix bugs across the runtime, platform, integration packages and cluster, and add missing @stability unstable and @stability experimental tags to modules that shipped untagged in Effect 4.0.0. The tags correct an accidental stability promise made by the implicit rule that unannotated APIs are stable; the release changes no behavior, signatures or types, and the Effect language service now warns on unstable API use and runs an apiStabilityLeak diagnostic. Spans and metrics from HTTP, SQL, RPC and AI now follow OpenTelemetry semantic conventions, and almost 30 people landed 150 commits on main in the first week.", "body_md": "A week ago we released [Effect 4.0](https://effect.website/blog/releases/effect/40). Since then, almost 30 people have landed 150 commits on `main`, and we’ve shipped two patch releases: **4.0.1** on October 5 and **4.0.2** today.\n\nBoth releases are mostly bug fixes across the runtime, the platform and integration packages, and cluster. The one change you might notice: spans and metrics from HTTP, SQL, RPC and AI now follow the OpenTelemetry semantic conventions, so they show up correctly in standard observability tools.\n\nThe full list is in the [changelog](https://github.com/Effect-TS/effect/blob/main/packages/effect/CHANGELOG.md).\n\nBut we’re also correcting a gnarly mistake we made in the lead-up to the release.\n\n## \n\nEffect 4.0 shipped with a simple rule. APIs tagged `@stability unstable` or `@stability experimental` may change in minor or patch releases, whilst **everything without an annotation is implicitly presumed stable**.\n\nThat implicit default bit us. Some modules that were intended to ship as unstable went out without a tag, so by our own rule, 4.0.0 promised they were stable. We missed it in review. That’s on us.\n\nWith today’s release, we are adding the missing tags. They cover a set of modules in `effect` and the integration packages around it, all of which are either entirely new in 4.0 or were already experimental or unstable before.\n\nStrictly speaking, narrowing a promise after a release is a breaking change in itself. We decided we must correct it now regardless. The release was only a week ago, but keeping this accidental promise would lock in designs that haven’t seen enough production use yet. That’s far cheaper to fix today than a year from now.\n\n### \n\nNothing in your code changes. This release does not alter any behavior, signatures or types of the affected modules. The [API reference](https://effect.website/docs/v4/api) shows the stability of every module and export.\n\n### \n\nEvery module and every directly importable export now declares its stability explicitly. We enforce this with automated checks in our pipeline.\n\nThe [Effect language service](https://effect.website/docs/v4/getting-started/devtools) builds on these tags:\n\n- **In your code** , it warns whenever you use an API marked`@stability unstable` or`@stability experimental` . Once you’ve decided to rely on one, you can allow it per module or per export with`allowedUnstableApis` and`allowedExperimentalApis` .\n- **In ours** , the new`apiStabilityLeak` diagnostic reports any stable API whose signature exposes a less stable type, so an unstable type can’t quietly become part of a stable API. If you publish Effect libraries, you can turn it on for your own packages too.\n\n### `unstable` directory\n\nDuring the beta and release candidates, unstable modules lived under `effect/unstable/*`. Explicit tags and the language service do that job better:\n\n- **They’re precise.** Stability applies to individual exports, not just whole modules, so a single new function can be unstable inside an otherwise stable module.\n- **Promotion doesn’t break anything.** With a directory, promoting a module to stable means moving it, and moving a module is a breaking change. That would not be a good start for a freshly promoted module. With tags, only the tag changes and your imports stay the same.\n- **You see it where it matters.** The warning appears where you use a module, and you decide exactly which level of stability you accept on a granular basis.\n\n## \n\nUpgrade the `@effect/*` packages alongside it, since they all share the same version.\n\nThank you to everyone who upgraded in the first week, filed issues, and sent pull requests. Keep them coming.\n\n[Previous Module of the Week - Cluster, Part 2](https://effect.website/blog/module-of-the-week/cluster-messaging)", "url": "https://wpnews.pro/news/effect-4-0-the-first-week", "canonical_source": "https://effect.website/blog/effect-4-first-week/", "published_at": "2026-10-07 17:48:02.811551+00:00", "updated_at": "2026-10-07 17:48:04.990692+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["Effect", "Effect-TS", "Effect 4.0", "Effect 4.0.1", "Effect 4.0.2", "Effect language service", "OpenTelemetry"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/effect-4-0-the-first-week", "markdown": "https://wpnews.pro/news/effect-4-0-the-first-week.md", "text": "https://wpnews.pro/news/effect-4-0-the-first-week.txt", "jsonld": "https://wpnews.pro/news/effect-4-0-the-first-week.jsonld"}}