fix(tanstackstart-react): Add workerd and worker export conditions

[smorimoto]

Problem

When deploying a TanStack Start application to Cloudflare Workers, importing @sentry/tanstackstart-react causes a build failure.

The @cloudflare/vite-plugin configures resolve conditions as ["workerd", "worker", "module", "browser"] for the SSR environment. Since this package only defines browser and node conditions, the resolver falls through to browser, which points to index.client.js. TanStack Start's import-protection plugin denies files matching **/*.client.* in the server environment, causing the build to fail.

Related: TanStack/router#6688

Solution

Add workerd and worker export conditions to the . entry in package.json, pointing to index.server.js (the same target as the node condition). This ensures that bundlers targeting Workers runtimes resolve to the server entry rather than falling through to the browser condition.

Users deploying to Cloudflare Workers will need nodejs_compat enabled in their wrangler configuration for @sentry/node to function correctly at runtime.

A dedicated Cloudflare entrypoint (without @sentry/node dependency) will be addressed in a follow-up PR.

Changed files

File	Change
packages/tanstackstart-react/package.json	Add workerd and worker export conditions pointing to index.server.js

[JPeer264]

Hey @smorimoto thanks for your PR and help to improve things going forward. I was looking over a PR. Do you have any examples on how this should look like in a production code? How is @sentry/tanstackstart-react/cloudflare being used in your Cloudflare environment?

In general I'm not quite sure just yet where Cloudflare specifics of SDKs should land. If you want to make it possible to get basic Cloudflare support you can have the following server.ts:

import { withSentry } from '@sentry/cloudflare';
import handler, { createServerEntry } from '@tanstack/react-start/server-entry';

const requestHandler = withSentry(() => ({
  dsn: '<YOUR_DSN>',
  tracesSampleRate: 1,
}), {
  async fetch(request: Request) {
    return handler.fetch(request);
  },
});

export default createServerEntry(requestHandler);

And have this file as entrypoint in your wrangler.jsonc

[smorimoto]

Thanks for the review and the suggestion, @JPeer264!

Regarding the @sentry/cloudflare approach with withSentry in server.ts — that would indeed handle SDK initialisation on the Cloudflare side. However, the underlying build problem would still remain: when TanStack Start's server-side code imports @sentry/tanstackstart-react, the @cloudflare/vite-plugin configures resolve conditions as ["workerd", "worker", "module", "browser"]. Without workerd/worker conditions pointing to a Node-free entrypoint, the resolver falls through to the browser condition (index.client.js), which TanStack Start's import-protection plugin then rejects because *.client.* files are not permitted in the server environment. Even if we only added the export conditions without the cloudflare entrypoint, they would resolve to index.server.js which re-exports @sentry/node — causing runtime errors in Workers due to missing Node.js APIs.

It's also worth noting that this PR follows the same pattern already established by @sentry/remix and @sentry/react-router, both of which have dedicated src/cloudflare/index.ts entrypoints and worker export conditions pointing to them:

• @sentry/remix: src/cloudflare/index.ts with "worker" in . exports
• @sentry/react-router: src/cloudflare/index.ts with "worker" in . exports

So this approach keeps things consistent across the Sentry SDK ecosystem rather than introducing a different pattern for TanStack Start specifically.

Happy to discuss further if you have any concerns!

[JPeer264]

I'm totally not against adding the worker, it is even a good thing to have.

I was just unsure how you would use the Cloudflare export as I haven't seen an E2E test or any example in the PR description. Would you use @sentry/tanstackrouter-react/cloudflare everywhere throughout your app, or would it be only in server.ts and start.ts.

If there are example we can add E2E tests for it, which is up to you if you add them or we add them for you in this PR.

Even if we only added the export conditions without the cloudflare entrypoint, they would resolve to index.server.js which re-exports @sentry/node — causing runtime errors in Workers due to missing Node.js APIs.

About that. Did you enable nodejs_compat in the wrangler.jsonc? As it should work with this option enabled - so we could theoretically leave @sentry/node. In the future we would also include @sentry/node in the @sentry/cloudflare package to enable certain integrations, and in my tests back in the days it worked fine.

If that is correct, we could reduce the PR to only add the new Cloudflare exports.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[smorimoto]

Thanks for the feedback, @JPeer264!

You raise a good point about nodejs_compat. I've simplified this PR to only add the workerd and worker export conditions, pointing them to index.server.js (same as the node condition). This is now a single 8-line change to package.json.

This resolves the build-time issue: without these conditions, the @cloudflare/vite-plugin's resolve conditions (["workerd", "worker", "module", "browser"]) fall through to browser, which resolves to index.client.js. TanStack Start's import-protection plugin then rejects *.client.* files in the server environment, causing the build to fail. With these conditions in place, the resolver picks up index.server.js before reaching browser.

For runtime, users would need nodejs_compat enabled in their wrangler configuration for @sentry/node to work on Workers, as you suggested.

A dedicated Cloudflare entrypoint (without @sentry/node dependency) — following the pattern in @sentry/remix and @sentry/react-router — would still be worth having in a follow-up PR to properly support edge runtimes without requiring nodejs_compat.