[joshamaju]

Motivation

Effection Context dependencies are currently runtime-only and invisible in operation types. TypeScript users cannot see which contexts an operation needs or verify that a composition provides them.

This is intentionally experimental: the design adds type-level contracts and provisioning APIs that need iteration outside the stable type surface.

Approach

• Export typed Context APIs from effection/experimental; the stable effection declarations retain their existing signatures.
• Add literal context identities with createContext<T, "name">("name"), then infer operation requirements from yield* Context.expect().
• Add Context.of(value), Context.from(operation), and provide(...bindings, operation).
• Evaluate providers left-to-right in a scoped boundary. Later providers may use earlier bindings, and provided resources remain active through the child operation.
• Provide typed wrappers for Context.with(), resource(), scoped(), and all() from the experimental entry.
• Add grouped compile-time API coverage, including expected failures and a check that provide is not a stable export.

Design considerations

• Requirement names identify dependencies; value types alone cannot distinguish separate contexts that carry the same type.
• provide accepts lazy operations, preserving Effection execution and scope ownership.
• Provider order is meaningful: a later binding cannot satisfy an earlier provider’s setup.
• Module augmentation of the stable createContext import was considered but removed: JSR does not support ambient module declarations that modify another module’s types. Users opt in by importing the typed constructor from effection/experimental instead.

Verification

• deno fmt deno.json lib/context.ts
• deno lint deno.json lib/context.ts lib/typed-context.ts experimental.ts test/typed-context.test.ts
• deno check mod.ts experimental.ts test/typed-context.test.ts

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/effection@1236

commit: 1a34edc

[codspeed]

Merging this PR will not alter performance

ℹ️ 1 benchmark has no flame graph

The flamegraph could not be generated because too much time was spent in runtime internals, making the visualization not useful for performance analysis.

• effection.events

✅ 6 untouched benchmarks

---

_{Comparing joshamaju:experimental/typed-context (1a34edc) with v4 (b1e1f5f)}

[joshamaju]

Apparently JSR doesn't allow publishing a package with module augmentation.