captureRouterTransitionStart missing from index.types.d.ts — linters report 'not found in namespace'

[sugurutakahashi-1234]

Description

captureRouterTransitionStart is exported from the browser condition entry point (index.client.js), but is not included in the types condition entry point (index.types.d.ts).

This causes ESLint import/namespace rules (e.g., oxlint) to report:

"captureRouterTransitionStart" not found in imported namespace "@sentry/nextjs"

The function works correctly at runtime because the browser bundler resolves the browser condition. However, static analysis tools resolve the types condition and cannot find the export.

Steps to Reproduce

1. Follow the official manual setup guide
2. Add to instrumentation-client.ts:

   import * as Sentry from "@sentry/nextjs";
   export const onRouterTransitionStart = Sentry.captureRouterTransitionStart;

3. Run a linter with import/namespace rule (e.g., oxlint, eslint-plugin-import)

Expected Behavior

No lint error — captureRouterTransitionStart should be found in the @sentry/nextjs namespace.

Actual Behavior

"captureRouterTransitionStart" not found in imported namespace "@sentry/nextjs"

Root Cause

In @sentry/nextjs/package.json exports:

Condition	Entry Point	Has captureRouterTransitionStart?
types	index.types.d.ts	❌ No
browser	index.client.js	✅ Yes
node	index.server.js	❌ No (expected)

The types entry should include client-only exports so that static analysis tools can resolve them.

Verified in @sentry/nextjs@10.43.0:

• build/types/client/index.d.ts exports captureRouterTransitionStart
• build/types/index.types.d.ts does not re-export it

Environment

• @sentry/nextjs: 10.43.0
• Linter: oxlint 1.51.0
• Next.js: 16.1.6
• Runtime: Bun 1.3.11

[linear-code]

JS-1985

[logaretm]

The type is actually exported in client/index.ts which in turn is re-exported by index.types.ts and this works fine because typescript is happy.

This looks like a quirk by import/namespace rule, since they are assuming a node runtime rather than a browser runtime for that file. I'm not sure how this would even work for other libraries since this is a very common pattern, the rule doesn't seem to be configurable to allow for explicit runtimes either.

Technically I think this is not a bug on our side since the only way to fix it is to export a NO-OP function of the same name on the server side (created a draft PR for it just now), but then that shouldn't be present in runtime and if that happens then there is a serious resolver issue the user needs to be aware of which will be hidden away by this "fix".

I will check with the team if this is a viable fix, but for now you can disable this rule specifically for that line.

// oxlint-disable-next-line import/namespace
// -- or --
// eslint-disable-next-line import/namespace
export const onRouterTransitionStart = Sentry.captureRouterTransitionStart;

Note that ignoring it doesn't affect types, the function is typed and typescript is resolving it just fine. The namespace rule isn't using types, it uses actual JS files.

Alternatively, you can add eslint-import-resolver-typescript resolver that should handle this case:

  npm install -D eslint-import-resolver-typescript                                                                                                                     

  // eslint.config.mjs                                                                                                                                                 
  settings: {                                                                                                                                                          
    "import/resolver": {                                    
      typescript: {
        conditionNames: ["types", "browser", "import", "default"],
      },                                                                                                                                                               
    },
  },    

For oxlint, I don't think that's supported at the moment. Worth checking or filing an issue with them.

[logaretm]

Created an issue with oxlint, since eslint already resolves this with other resolvers.

oxc-project/oxc#20704