Skip to content

feat(runtime): add generator-based runtime for the generator context pattern - #4

Merged
jhnns merged 2 commits into
mainfrom
generator-context-toolkit
Aug 3, 2026
Merged

feat(runtime): add generator-based runtime for the generator context pattern#4
jhnns merged 2 commits into
mainfrom
generator-context-toolkit

Conversation

@jhnns

@jhnns jhnns commented Aug 3, 2026

Copy link
Copy Markdown
Member

Adds a new runtime utility implementing the generator context pattern: createRuntime<Context>() returns action to define context-dependent operations, call/provide to compose workflows, and run to execute one against a real or mocked context, so workflows request dependencies via yield* instead of threading them through every signature.

Workflow<Return, Context> carries the context type, so passing a workflow to a runtime that can't supply its dependencies is a compile error rather than a silent undefined at runtime; call/provide operations are single-use and throw on a second yield*, since they own the generator instance they were given.

Ships at 356 B brotli (375 B budget) with the usual README, package.json/jsr.json exports, .size-limit.json entry, and 18 tests including @ts-expect-error cases pinning the cross-runtime type checks.

The single-use guard uses a small internal singleUse helper in runtime.lib.ts rather than concurrency/exactlyOnce, which is async-only and carries a passive promise property — more than this needs, and more bytes than the budget allows.

🤖 Generated with Claude Code

…pattern

Workflows request dependencies on demand via `yield*` instead of having
them threaded through every function signature. `createRuntime<Context>()`
returns `action` to define context-dependent operations, `call` and
`provide` to compose workflows, and `run` to execute one against a real
or mocked context.

`Workflow<Return, Context>` carries the context type so the compiler keeps
workflows from different runtimes apart, and `call`/`provide` operations
are single-use since they own the generator instance they were given.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jhnns
jhnns force-pushed the generator-context-toolkit branch from 3f5992c to 70132f1 Compare August 3, 2026 09:19
These four failures predate this branch — `main` has been red on the
"Test and Release" workflow since 94af6d7. `run-p` aborts siblings on the
first failure, so only `test:jsr` surfaced in the logs.

- test:jsr: `parseRetryAfter`'s `now` parameter had no explicit type, which
  JSR's no-slow-types check rejects for public API symbols.
- test:types: `lib` lost `dom` when it moved to es2024, so `RequestInfo`
  (src/api/api.test.ts) and `VoidFunction` (@tanstack/query-core's .d.ts,
  checked because skipLibCheck is false) no longer resolved. Emitted output
  is byte-identical with and without `dom`, so this is typecheck-only.
- test:lint: `no-redundant-type-constituents` fired on the unresolved
  `RequestInfo`; fixed by the same `lib` change.
- test:build: `sleep` grew to 180 B in a6b60a3 without its limit or README
  claim being updated.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@jhnns
jhnns merged commit f2f6f3f into main Aug 3, 2026
3 of 4 checks passed
@jhnns

jhnns commented Aug 3, 2026

Copy link
Copy Markdown
Member Author

Closes #1

@jhnns
jhnns deleted the generator-context-toolkit branch August 3, 2026 12:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant