fix(cloudflare): Restore env type inference for options callbacks - #22963
Open
JPeer264 wants to merge 2 commits into
Open
fix(cloudflare): Restore env type inference for options callbacks#22963JPeer264 wants to merge 2 commits into
JPeer264 wants to merge 2 commits into
Conversation
The env parameter of the options callbacks of withSentry, instrumentDurableObjectWithSentry and instrumentWorkflowWithSentry collapsed to unknown when the handler was typed via satisfies, a pre-typed constant, a Hono app or a bare WorkerEntrypoint / DurableObject / WorkflowEntrypoint class, so property access on env failed to compile. Resolve the callback env from the passed handler first (its handler methods or class constructor), then the explicit Env generic, then the wrangler-generated Cloudflare.Env, and fall back to any so untyped setups keep compiling. Also loosen the constructor constraint of instrumentWorkflowWithSentry: workers-types defaults WorkflowEntrypoint's Env to unknown (unlike WorkerEntrypoint / DurableObject), so bare workflow classes were rejected in wrangler-types projects. Add a tsc type-test suite to the Cloudflare integration tests covering the inference scenarios against workers-types v4 and the built d.ts, including a separate program simulating a wrangler types project, and drop the now-unneeded @ts-expect-error in the TanStack Start e2e app. Co-Authored-By: Claude <noreply@anthropic.com>
JPeer264
requested review from
andreiborza and
mydea
and removed request for
a team
August 3, 2026 14:38
Contributor
size-limit report 📦
|
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
1 participant
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.
closes #18294
closes #18294
Our types were pretty messed up and we didn't have any tests if we break something. Since there is now
workers-typesv4 AND v5 we need to have a kinda matrix. To keep it simple the matrix is just 2 different ts configs:tsconfig.v4.jsonandtsconfig.v5.jsonWe need to support different ways of writing while keeping the
envtypes in tact. Those are some samples:It seems by just setting
Envin the generics toanyhas done the trick, but needs some more type helpers in order to get the correctEnvin the options, based on the different ways of writing it.Clanker generated output:
The env parameter of the options callbacks of
withSentry,instrumentDurableObjectWithSentryandinstrumentWorkflowWithSentrycollapsed to unknown when the handler was typed via satisfies, a pre-typed constant, a Hono app or a bare WorkerEntrypoint / DurableObject / WorkflowEntrypoint class, so property access on env failed to compile.Resolve the callback env from the passed handler first (its handler methods or class constructor), then the explicit Env generic, then the wrangler-generated Cloudflare.Env, and fall back to any so untyped setups keep compiling. Also loosen the constructor constraint of instrumentWorkflowWithSentry: workers-types defaults WorkflowEntrypoint's Env to unknown (unlike WorkerEntrypoint / DurableObject), so bare workflow classes were rejected in wrangler-types projects.
Add a tsc type-test suite to the Cloudflare integration tests covering the inference scenarios against workers-types v4 and the built d.ts, including a separate program simulating a wrangler types project, and drop the now-unneeded @ts-expect-error in the TanStack Start e2e app.