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({
    // ...
  })]
})

[adishua]

I am also experiencing a similar issue.
I added the data fetching functions and got the following compilation warnings on nextjs build (nx):

./pages/_app.tsx
Attempted import error: 'withSentryServerSideAppGetInitialProps' is not exported from '@sentry/nextjs' (imported as 'withSentryServerSideAppGetInitialProps').

./pages/_error.tsx
Attempted import error: 'withSentryServerSideErrorGetInitialProps' is not exported from '@sentry/nextjs' (imported as 'withSentryServerSideErrorGetInitialProps').

../../libs/shared/utils/src/lib/session.ts
Attempted import error: 'withSentryGetServerSideProps' is not exported from '@sentry/nextjs' (imported as 'withSentryGetServerSideProps').

The build is eventually passing but the error page is broken (it doesn't find withSentryServerSideErrorGetInitialProps in real-time)

I see that they are exported directly under @sentry/nextjs (from ./config/wrappers) and they are actually recognized when I am running the nextjs dev server (nx) but not on production using the build

Any idea why does it happening and how can it be fixed?

[lforst]

@adishua Can you share your _error page?

[adishua]

Yes.

import { withSentryServerSideErrorGetInitialProps } from '@sentry/nextjs';
import type { NextPage } from 'next';
import NextErrorComponent, { ErrorProps } from 'next/error';

const CustomErrorComponent: NextPage<ErrorProps> = ({ statusCode }) => {
  return <NextErrorComponent statusCode={statusCode} />;
};

CustomErrorComponent.getInitialProps = withSentryServerSideErrorGetInitialProps(
  (context) => {
    return Promise.resolve(NextErrorComponent.getInitialProps(context));
  }
);

export default CustomErrorComponent;

The result of it is a white screen (instead of the standard error page) with the following errors on the browser console:

main-de2739d1da139b08.js:1 TypeError: (0 , i.withSentryServerSideErrorGetInitialProps) is not a function
    at 90740 (_error-88201325d37f398f.js:1:390)
    at c (webpack-41e4e2d1eb0c0667.js:1:161)
    at _error-88201325d37f398f.js:1:158
    at main-de2739d1da139b08.js:1:23497
main-de2739d1da139b08.js:1 A client-side exception has occurred, see here for more info: https://nextjs.org/docs/messages/client-side-exception-occurred
_error-88201325d37f398f.js:1 Uncaught (in promise) TypeError: (0 , i.withSentryServerSideErrorGetInitialProps) is not a function
    at 90740 (_error-88201325d37f398f.js:1:390)
    at c (webpack-41e4e2d1eb0c0667.js:1:161)
    at _error-88201325d37f398f.js:1:158
    at main-de2739d1da139b08.js:1:23497

[lforst]

@adishua I think I know what is going on. withSentryServerSideErrorGetInitialProps is not available on the clientside. Why did you choose to manually wrap this function? Did you turn off autoInstrumentServerFunctions?

[adishua]

yes.. the auto instrument didn't work for me, I had to wrap the getServerSideProps in order to see the errors, then I implemented the rest of the data-fetching wrappers.

[lforst]

Ok, thanks for letting us know about this. I actually want to fix this soon by making the Next.js SDK fully isomorphic. For now what you can try is to wrap your getInitialProps another time and only wrap the original one with withSentryServerSideErrorGetInitialProps when run on the server (typeof window === 'undefined').

At some point soon-ish we will do this in the wrapper itself.

[adishua]

I'll try that. Thanks

[adishua]

It didn't help. I got the same error with the following implementation

CustomErrorComponent.getInitialProps = async (context) => {
  if (typeof window === 'undefined') {
    return NextErrorComponent.getInitialProps(context);
  }
  return (
    await import('@sentry/nextjs')
  ).withSentryServerSideErrorGetInitialProps((context) => {
    return Promise.resolve(NextErrorComponent.getInitialProps(context));
  })(context);
};

(I also tried to import the function dynamically but that didn't help)