[sentry/cloudflare] Sentry import breaks Env type

[shmuli9]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/cloudflare

SDK Version

9.13.0

Framework Version

React Router 7.5.1, Vite 6.3.0, Wrangler 4.12.0

Link to Sentry event

No response

Reproduction Example/SDK Setup

// worker file: ./workers/app.ts

import { getLoadContext } from "load-context";
import { createRequestHandler } from "react-router";
import * as Sentry from "@sentry/cloudflare"; // <-- this line breaks the Env types

const requestHandler = createRequestHandler(
  () => import("virtual:react-router/server-build"),
  import.meta.env.MODE
);

export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    if (url.pathname.startsWith("/r2")) {
      const key = url.pathname.replace(/^\/r2\//, "");
      const object = await env.BUCKET.get(key);
      if (!object) {
        return new Response("Not found", { status: 404 });
      }
      return new Response(object.body, {
        headers: { "Content-Type": "image/jpeg" },
      });
    }

    const loadContext = getLoadContext({
      request,
      context: { cloudflare: { env, ctx } },
    });
    return requestHandler(request, loadContext);
  },
} satisfies ExportedHandler<Env>;

Steps to Reproduce

1. installed @sentry/cloudflare v9.13.0
2. added the import to workers/app.ts
import * as Sentry from "@sentry/cloudflare"; // <-- this line breaks the Env types
3. my env types break in when i typecheck
4. commenting out the import fixes the type errors
   // import * as Sentry from "@sentry/cloudflare";

Expected Result

Types should not be corrupted by import Sentry

Actual Result

Broken:

Working (when import is commented out):

[lforst]

I cannot reproduce this in the exact way you're describing. I am getting a type error on env.BUCKET however that is unrelated to Sentry and simply happens when I run npm run cf-typegen or wrangler types.

Commenting and uncommenting the import doesn't change anything for me. Would you mind sharing a reproduction example we can pull?

[SlexAxton]

I'm also experiencing this behavior. It exists when using the newest wrangler setup. In newer setups the root typescript does not include @cloudflare/workers-types but instead includes ./worker-configuration.d.ts. This file is generated with wrangler types.

Then my tsconfig has something like this in it:

         "compilerOptions": {
		"lib": ["DOM", "DOM.Iterable", "ES2023"],
		"types": ["./worker-configuration.d.ts", "vite/client"],
		"baseUrl": ".",
		"rootDirs": [".", "./.react-router/types"],
	}

I don't even have @cloudflare/workers-types installed at all.

So when I add import * as Sentry from @sentry/cloudflaresuddenly theEnvdefinition in my whole app is empty, and refers to the transitive dependency on@cloudflare/workers-typesin@sentry/cloudflare`.

If I use the new wrangler features for import { env } from 'cloudflare:workers'; and then i cmd-click on env - i am bought to the @cloudflare/workers-types definition in the sentry dependency now.

But if I remove the import to sentry, this no longer occurs.

My wrangler version is 4.13.1

My app is based on this template: https://github.com/cloudflare/templates/blob/staging/react-router-postgres-ssr-template

So that's likely a good spot to test an integration.

[SlexAxton]

It's also possible that this is some artifact of pnpm too. So I should mention that I'm also using pnpm

[SlexAxton]

I think it's possible that it is a pnpm related issue, or rather, a monorepo one.

I have @cloudflare/workers-types installed in a different package that still uses it. So the package exists in my root folder. Then for the @sentry/cloudflare project it's listed as an optional peerDependency. So I think in many cases folks won't run into this unless some other package has installed it. BUT once it's in the node_modules folder, it is loaded along with @sentry/cloudflare and blows away the Env types from ./worker-configuration.d.ts.

I tried a bunch of ways to try to make this go away. I was hopeful that just a line like this in my tsconfig.json would do the trick:

{
  "paths": {
    "@cloudflare/workers-types": "./empty.d.ts"
  }
}

I also tried the overrides functionality in pnpm but couldn't figure out an incantation that worked for me.

Eventually I got a hacky solution, that works for now. Maybe it's helpful to someone else until this is resolved.

I found a unique version of @cloudflare/workers-types in the 4.x range, so that it would meet the peerDependency for @sentry/cloudflare, and installed it to my project in devDependencies. In my case, no other project was using 4.20250430.0

Then I ran pnpm patch @cloudflare/[email protected]

Then I hopped into the folder that it generates for you and patched both index.ts and index.d.ts to just be a single line:

export {};

Once both those files were replaced with that line, I ran the patch-commit command to create the patch:

pnpm patch-commit '/Users/you/your/project/node_modules/.pnpm_patches/@cloudflare/[email protected]'

Then I ran pnpm install to load in the patched version of the dependency. And now my Env variables and cloudflare stuff more generally all resolves to my worker-configuration.d.ts file again.

Definitely a short term fix, but hopefully it unblocks someone!

[shmuli9]

@SlexAxton your setup exactly matches mine. Monorepo, pnpm, recent wrangler upgrade
Thanks for posting your patch fix!
I've put my sentry integration on hold due to this, but I'll take another look and see if your method works for me too

[AbhiPrasad]

I'm curious what happens if you report this to pnpm, perhaps they'll consider it a bug on their side?

Longer term we should try to find a way where we can avoid having the peer dep with @cloudflare/workers-types - relying on generics and inferencing the types passed in structurally should be good enough for the most part.

we still need the dep (and in fact it's what cloudflare themselves recommends for libraries), but I think we can avoid doing it this way.