Uh oh!
There was an error while loading. Please reload this page.
fix(cloudflare): Use correct env types for withSentry - #19836
Conversation
d781f4c to
5fbcf2dComparesize-limit report 📦
|
| */ | ||
| export function withSentry< | ||
| Env = unknown, | ||
| Env = typeof env, |
There was a problem hiding this comment.
q: Isn't this theoretically breaking?
There was a problem hiding this comment.
I don't really see this as a breaking change, as Env is only there so it gets inferred by the third generic entry, which I think just grew over time. So there are couple of usages and non of them look breaking to me:
// sets "Env" directly, so it isn't affected at allwithSentry<{myEnv: string}>()// "Env" is manually set, which means it is the same type nowwithSentry((env: Env)=>({}),exportedHandler)// Not setting anything, this wasn't working before, but works with this PRwithSentry(env=>({}),exportedHandler)It could also be that people used not existing env variables, which wouldn't work as the exported handler is already typed, as documented, with the env usually (which is the same behavior with and without this PR):
constexportedHandler={fetch(){}}satisfiesExportedHandler<Env>withSentry((env: {notExistingEnv: string})=>({}),exportedHandler)^^^^^^^^^^^^^^^
closes#18294
closes JS-1202
By not using
unknownbut going directly to theenvexport ofcloudflare:workers, this should resolve the typing issue, without changing the current generic API (as proposed in #18302).The test proofs that when changing the Cloudflare globals, that this works OOTB now.