Question 1

How do I migrate async TypeScript code to Effect incrementally?

Accepted Answer

Extract an interface with Effect-returning methods, declare a Context.Service class, build a Layer.effect capturing dependencies, and bridge to legacy callers via a ManagedRuntime with runPromise. Migrate Effect callers to yield* the service directly, then prune dead facades in a separate commit.

Question 2

How to keep backward compatibility when converting Promise APIs to Effect?

Accepted Answer

Keep thin async facade functions that delegate to a runtime bridge's runPromise method. These facades serve remaining non-Effect callers only; once all callers yield the service directly, delete the facades and bridge in a dedicated cleanup commit.

Question 3

How do I replace Promise.all with Effect concurrency?

Accepted Answer

Replace Effect.promise wrapping Promise.all(items.map(...)) with Effect.forEach(items, fn, { concurrency: 'unbounded' }). This removes the Effect.promise wrapper entirely and gives explicit control over concurrency behavior.

Question 4

Why use a shared memoMap with ManagedRuntime in Effect?

Accepted Answer

A shared memoMap from Layer.makeMemoMapUnsafe deduplicates layer allocations across all per-service runtimes. Forking the memo map isolates new allocations and defeats the deduplication the runtime bridge exists to provide.

Question 5

What happens to error handling when migrating from Effect.promise to services?

Accepted Answer

Errors that previously flowed as defects through Effect.promise become typed channel errors when calling services directly. Update existing catchDefect handlers to catch or catchTag so the now-typed errors are handled in the error channel.

effect-incremental-migration

SYSTEM DOCUMENTATION & REQUIREMENTS

Frequently Asked Questions about effect-incremental-migration

Related Skills

effect-incremental-migration

error-handling

building-storefronts

dv-connect