Effect v3 to v4 Migration

Drive an Effect v3 → v4 migration from the generated migration reference that ships in the Effect repo. Every rename, removal, and signature change is answered by upstream data — do not guess replacements.

Workflow

Work through these steps in order; each one is detailed in the section named.

Set up and validate the local checkouts — two shallow clones; verify any pre-existing
```
.repos/effect
```
before trusting it. See Setup: Local Checkouts.
Read
MIGRATION.md
and
```
ls .repos/effect/migration/
```
for the background and guide index. See Reading Order.
Migrate
package.json
— remove consolidated packages, align every remaining Effect package on one v4 version. Do this before type-checking, or the first run drowns in unresolved-import noise from packages that no longer exist. See Repo-Level Changes.
Run the project's type-check (e.g.
```
tsc --noEmit
```
) to get the initial error inventory.
Iterate until the type-check is clean. For each error, resolve the API through the lookup discipline — search
```
migration/v3-to-v4.md
```
for the symbol, escalate per Reading Order — then fix the call site, delegating per-file fixes to sub-agents per Delegating to Sub-Agents. Never silence an error instead of resolving it; see Hard Prohibitions.
Finish — type-check clean; run tests and report their outcome honestly (not a gate); write the final summary. See Done Condition.

Setup: Local Checkouts

The migration is driven from two shallow, single-branch clones of the canonical Effect repo:

git clone --depth 1 --single-branch https://github.com/Effect-TS/effect .repos/effect
git clone --depth 1 --single-branch --branch v3 https://github.com/Effect-TS/effect .repos/effect-v3

```
.repos/effect
```
— v4 (
```
main
```
). Contains
```
MIGRATION.md
```
, the
```
migration/
```
guides, and the v4 source.
```
.repos/effect-v3
```
— v3 (
```
v3
```
branch). Escalation-only reference for old semantics.

Each clone is independently re-runnable and separately deletable. Do not use

git worktree

to share one clone between branches.

Validate an existing checkout before trusting it

./.repos/effect

may already exist, cloned from the archived

Effect-TS/effect-smol

repo by older setup instructions. That checkout is dead: it is stale and does not contain

migration/v3-to-v4.md

. Verify before using:

git -C .repos/effect remote get-url origin   # must be the canonical Effect-TS/effect repo
node -p "require('./.repos/effect/packages/effect/package.json').version"   # must be 4.x

If the origin points at

effect-smol

, or the version is not

4.x

, delete the directory and re-clone as above.

Reading Order

Front-load
MIGRATION.md
once (
```
.repos/effect/MIGRATION.md
```
).
migration/v3-to-v4.md
— the first stop for every API. The generated reference covers every removed or changed API. Search it (see below); never read it whole.
A per-topic guide (
```
.repos/effect/migration/*.md
```
) when the mapping implies a rewrite rather than a rename — e.g.
```
Context.Tag
```
→
```
Context.Service
```
is a structural change, not a symbol swap. Reach these on demand from the
```
MIGRATION.md
```
index, not front-loaded.
v4 source (
```
.repos/effect/packages/*/src/
```
, including
```
unstable/
```
) to confirm a replacement's real signature before writing code against it.
v3 source (
```
.repos/effect-v3
```
) as escalation only — for when unsure about the old v3 semantics.

Never Read the Reference Doc Whole

This is the single most important rule in this skill.

migration/v3-to-v4.md

is ~16,000 lines / ~350k tokens. Reading it in one pass blows the context window and takes the migration with it.

Always search it and read only matched lines plus surrounding context. The file has four sections — Import Map, No Counterpart Imports, Removed Modules, and API Reference (one

### `<v3 module path>`

heading per module). Entries are grep-able one-liners of the form

- `Old.symbol` -> `New.symbol`: <rationale>

, and removals are explicit

-> `none`

entries with a stated alternative.

Concrete recipes:

# Look up a specific v3 symbol
rg -n 'AnthropicTokenizer\.layer' .repos/effect/migration/v3-to-v4.md

# Read a whole module's section via its heading
rg -n -A 40 '^### `@effect/platform/FileSystem`' .repos/effect/migration/v3-to-v4.md

# Resolve a v3 import path in the Import Map
rg -n '^@effect/platform/FileSystem ' .repos/effect/migration/v3-to-v4.md

# List every module section for a package
rg -n '^### `@effect/cluster/' .repos/effect/migration/v3-to-v4.md

Look up APIs as you encounter them, one search at a time. A miss in the Import Map is not a dead end — check the Removed Modules and No Counterpart Imports sections before concluding anything.

Repo-Level Changes

Faithful per-API lookup alone still yields a broken

package.json

. Handle these once, up front:

Package consolidation.
```
@effect/platform
```
,
```
@effect/rpc
```
,
```
@effect/cluster
```
, and others merged into the core
```
effect
```
package — remove them from
```
package.json
```
and rewrite their imports per the Import Map. Packages that remain separate (
```
@effect/platform-*
```
,
```
@effect/sql-*
```
,
```
@effect/ai-*
```
,
```
@effect/opentelemetry
```
,
```
@effect/vitest
```
, …) stay as dependencies.
Version alignment. All Effect ecosystem packages share one version number in v4. Every remaining
```
effect
```
/
```
@effect/*
```
dependency must be on the same matching version.
Unstable modules. Some functionality only exists under
```
effect/unstable/*
```
import paths (e.g.
```
effect/unstable/http
```
,
```
effect/unstable/rpc
```
). These are correct v4 imports — use them where the reference maps to them; they may receive breaking changes in minor releases.

Delegating to Sub-Agents

Per-file migration work is context-hungry; do it in sub-agents so the main session's context survives the whole migration.

Spawn one sub-agent per file (or per module), giving it the specific v3 symbols to resolve in that file.
The sub-agent returns the edit and the mappings it used; the main session keeps the error inventory and the running summary.
Sub-agents inherit the same lookup discipline (Reading Order, the
```
rg
```
recipes) and Hard Prohibitions.
The reference doc is never read whole in a sub-agent either — a blown sub-agent context still costs the migration that file.

Hard Prohibitions

Never reintroduce a v3-shaped compatibility layer. Writing a
```
v3-compat.ts
```
that re-exports old names makes type errors vanish and permanently freezes the codebase between versions. Migrate call sites to the v4 API.
No
any
, no
as
casts to silence a post-migration type error. Such an error is usually evidence the replacement has a different shape; casting deletes that information. Go back to the reference or the v4 source.
No invented APIs. Every replacement must trace to the reference doc, a topic guide, or the v4 source.

Done Condition

The project type-checks against v4. A v4 migration is fundamentally a type-level exercise; unresolved imports and changed signatures surface there and nowhere else. Run the project's type-check (e.g.

tsc --noEmit

) until clean.

Running the test suite is recommended, and its outcome must be reported honestly — but it is not a gate. A repo mid-migration often has tests that cannot run for unrelated reasons; do not weaken tests to make them pass.

The final summary must state: the type-check result, the test result (or why tests were not run), every constructed replacement, and any gaps that were reported rather than bridged.

effect-v3-to-v4

NPX Install

Tags

SKILL.md Content