Module '"@sentry/nextjs"' has no exported member 'BrowserTracing'.

[seanparmelee]

Hello 👋
I just updated to Sentry 6.17.7 and saw that BrowserTracing has since been directly exported through @sentry/nextjs so I went to update my sentry.client.config.ts file:

-import { Integrations } from '@sentry/tracing';
+import { BrowserTracing } from '@sentry/nextjs';

-integrations: [new Integrations.BrowserTracing(), new OfflineIntegration()],
+integrations: [new BrowserTracing(), new OfflineIntegration()],

But TypeScript is complaining about the import, saying

Module '"@sentry/nextjs"' has no exported member 'BrowserTracing'. ts(2305)

It seems TypeScript is looking in the server index file, rather than the client. I'm not sure there's a good way around this at the moment, aside from ignoring this error or also exporting BrowserTracing from the server file. I did come across microsoft/TypeScript#29128 which seems like what we'd need here.

[ariariel]

Similar issue here using the nextjs package (v6.18.2):

import * as Sentry from '@sentry/nextjs'

const {SENTRY_DSN} = process.env

Sentry.init({
 dsn: SENTRY_DSN,
 integrations: [new Sentry.BrowserTracing()],
 tracesSampleRate: 0.2,
})

And I get the following typescript error that Sentry.BrowserTracing does not exist:

Property 'BrowserTracing' does not exist on type 'typeof import("......./node_modules/.pnpm/@sentry+nextjs@6.18.2_next@10.2.3+react@17.0.2/node_modules/@sentry/nextjs/esm/index.server")'.ts(2339)

typescript is looking in the server index instead of client index. Though after building, webpack seems to locate the right index:

__webpack_require__(/*! @sentry/nextjs */ \"../../common/temp/node_modules/.pnpm/@sentry+nextjs@6.18.2_next@10.2.3+react@17.0.2/node_modules/@sentry/nextjs/esm/index.client.js\");

[lobsterkatie]

Yes, this is a known issue, and does indeed come from a lack of microsoft/TypeScript#29128 being solved. (I'm honestly surprised this isn't a more widespread problem.)

One option is to split the SDK and force all imports to come from @sentry/nextjs/node and @sentry/nextjs/browser. I did at one point write a script which essentially tries to create a Frankentypes file, but it had its own issues and as a team we decided not to go in this direction before I got it fully polished. (In case you're curious, it's here: https://github.com/getsentry/sentry-javascript/blob/f4a8573aa4f9f679804895355ddcf82b5f7f5933/packages/nextjs/scripts/generate-types.ts.)

Definitely open to better ideas if anyone has them!

[mmkal]

@lobsterkatie until the TypeScript issue is reopened/resolved, some options that come to mind:

1. Add no-op implementations of classes like BrowserTracing that run on the server side too, maybe logging an error (to Sentry!?) saying Error: this module has no effect in a server context. Developers are pretty used to that kind of thing if they're already writing code that runs in both contexts.

2. Have the typings include both, but certain things are undefined in certain contexts and will throw if you try to put them in the wrong config. Sentry can just document that certain integrations will only work on the server side, and some only on the client side.

3. Same as above, but to be a bit stricter, the non-isomorphic integrations could be typed something like

class _WhateverIntegration { ... }

export const WhateverIntegration: typeof _WhateverIntegration | undefined

to force developers to acknowledge that they're working with an integration that doesn't always exist.

4. Rely on module augmentation, so to use browser-only integrations, users would have to do something like:

import '@sentry/nextjs/browser'
import * as Sentry from '@sentry/nextjs'

Sentry.init({
 integrations: [new Sentry.BrowserTracing()]
})

Where @sentry/nextjs/browser is a d.ts file something like:

declare namespace NodeJS {
 interface Process {
 context: 'browser'
 }
}

Then the export could be defined as:

export type BrowserOnly<T> = NodeJS.Process['context'] extends 'browser' ? T : undefined

class _Whatever {}

export const Whatever: BrowserOnly<typeof _Whatever>

Of those, 1 would probably be the easiest, both for maintainers and users.

[geekysaurabh001]

Is this still not solved? Version 7 and the same problem in nextjs package.

[vamcs]

The simplest way I found in order to avoid having to explicitly ignore the errors and still have type completion was to add the package @sentry/tracing as a dependency and import BrowserTracing from it:

import { BrowserTracing } from '@sentry/tracing'

// ...
Sentry.init({
 // ...
 integrations: [new BrowserTracing({
 // ...
 })]
})