Repository navigation
Type the compiled execution plan without any casts - #258
Merged
Merged
Conversation
Contributor
Type performanceMeasured with TypeScript 6.0.3 and
Marginal instantiations are measured against the matching setup without that API call:
Check times (informational)
Type instantiations are the comparison metric. Check time varies with runner load and is informational only. |
Contributor
Runtime performanceMedian of 5 independent benchmark processes on Pull request baseline
Process runtime reference points
Effect Machine change from base
Process runtime reference change from base
Regression guardNo large, noise-adjusted throughput or heap regressions detected. Versions and interpretation
Higher throughput is better; lower heap is better. Variability is the median absolute deviation across independent processes, relative to their median. Small differences on shared GitHub-hosted hardware remain informational; the required guard rejects only large changes beyond the measured noise allowance. |
4 of 5 tasks
Give indexed dispatch explicit event, transition-context, snapshot-node, and microstep types, narrow initial targets before resolution, and make conflict resolution generic over the fields it reads. Command collectors accept the erased send/stop target types instead of casting unknown values. The emitted JavaScript is unchanged apart from local renames. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SandroMaglione
force-pushed
the
planner-typed-execution-plan
branch
from
November 1, 2026 09:31
a829583 to
8da00d6
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is part 1 of the planner/execution-layer cast cleanup and covers
executionPlan.ts. A follow-up PR handlesplanner.ts,invocation.ts,machine.ts, and the finite-model test adapter. There is no behavior change and no public API change.Casts removed (
grep -c "as any"/grep -c "as unknown as"):internal/machine/executionPlan.tsinternal/machine/command.tsHow:
IndexedEvent(the decoded event's_tag),IndexedTransitionContext(whatmakeIndexedTransitionContextbuilds, previouslyany), andIndexedMicrostep(keeps raised events typed for the next dispatch) replace theevent: any,context: any, and(selection.context as any).eventsites.collectIndexedTransitionis generic over its context.IndexedSnapshotNodedescribes the snapshot being built, replacingRecord<string, unknown>plusas unknown as AtomicSnapshotand the mutablecompletedassertion.initialTarget). After the existing snapshot-or-target check,targetis typed, so the eighttarget as any/unresolvedTarget as anysites go away. The retained unresolved target isinitialTarget ?? target, the same value as before: without an initial target, the validated target is the returned target.removeConflictingTransitions/sortEvaluatedTransitionsinplanner.tsare now generic over a minimalConflictCandidate(theselection.sourcePath,update, andexitPathsthey read) instead of the full five-parameterEvaluatedTransition. The indexed planner passes its own representation directly, with noevaluated as anyand no result assertion.SendToTarget/StopTargetincommand.ts(derived fromCommand) type thesendTo/stopcollectors in bothmakeCollectorand the indexed collector, sotarget as any/child as anygo away.MachineInternal.initialis typed as(...args: ReadonlyArray<unknown>) => unknownon the existingtoImplboundary, replacingmachine.initial(...inputArgs as any). The twomachine as any/event as anyarguments toplanConfigurationwere unnecessary and are dropped.One assertion remains, on purpose, at a genuine erased boundary, with a comment: the shared initial-target resolver in
planner.tsdecodes raised events but types themunknown, soinitialRaisedEventsis asserted toReadonlyArray<IndexedEvent>where generic-planner output enters the indexed representation. It is a narrow type assertion, notany.Emitted JavaScript: I compiled
srcfor base and PR and diffed the output.planner.jsis identical.executionPlan.jsandcommand.jsdiffer only by local renames, shorthand properties, and theinitialTarget/retainedTargetlocals.toImpl(machine).initialreplacesmachine.initial, andtoImplis an identity function used only at startup.Changeset
.changeset/typed-execution-plan.md, patch for@typeonce/effect-machinewith an "Internal: …" entry (the policy script requires a changeset for anypackages/effect-machine/src/change, and Check public Machine operations against their implementations #223 set the precedent for a patch on internal type-safety work).Validation
pnpm check(92 files / 901 tests, all tstyche suites, pack and consumer checks), including the existing forced generic-versus-indexed differential suitespnpm perf:typesshowed 0 change in every scenario (public inference is untouched). Type-checkingpackages/effect-machineitself went from 419,337 to 419,080 instantiations (−257); types went from 91,980 to 92,487 because of the new named interfaces. Check time showed no measurable difference in interleaved runs (base ≈3.3–4.0 s, PR ≈3.0–3.5 s, on a heavily loaded machine).pnpm perf:runtimebase and PR twice each, alternating, but the host was under load average ~25, so variability reached 20–78% MAD in both directions. That run can't show anything either way. Given the emitted-JS diff above, I expect no runtime change; the CI base-versus-PR comparison is authoritative.🤖 Generated with Claude Code