You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We were getting the following warnings in the console when running the local server:
β ./node_modules/.pnpm/@sentry+node@9.26.0/node_modules/@sentry/node/build/cjs/sdk
Package import-in-the-middle can't be external
The request import-in-the-middle matches serverExternalPackages (or the default list).
The request could not be resolved by Node.js from the project directory.
Packages that should be external need to be installed in the project directory, so they can be resolved from the output files.
Try to install it into the project directory by running npm install import-in-the-middle from the project directory.
Why were the warnings happening?
The Sentry SDK for Next.js tries to hook into Node.js internals using packages like import-in-the-middle and require-in-the-middle. When Sentry is imported at the top level on a file (even if not enabled), it tries to load these dependencies... If they are not installed, then we get these warnings...
Why does installing the packages fix it?
By installing import-in-the-middle and require-in-the-middle as dev dependencies, Sentry finds them and the warnings disappear. This is a safe workaround for local/dev, and does not affect production.
Loading Sentry conditionally
One way to avoid these warnings β οΈ is by loading Sentry conditionally. That is the approach I took in an earlier PR. However I realised that it would have to apply to any file importing Sentry:
import*asSentryfrom"@sentry/nextjs";
which would end quite messy and affecting a lot of files. I realised installing the packages is just simpler ( they won't in the bundle or affect page load ) and using enabled in the Sentry initialisation is also cleaner.
Checklist π
For code changes:
I have clearly listed my changes in the PR description
I have made a test plan
I have tested my changes according to the test plan:
There are not Sentry warnings when running the local dev server ( with or without --turbo )
Sentry still reports issues in production or staging ( but not locally )
The PR changes Sentry initialization from a conditional import to using the 'enabled' flag. Verify that this approach correctly prevents Sentry from initializing in non-production or non-cloud environments.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes ποΈ
We were getting the following warnings in the console when running the local server:
Why were the warnings happening?
The Sentry SDK for Next.js tries to hook into Node.js internals using packages like
import-in-the-middleandrequire-in-the-middle. When Sentry is imported at the top level on a file (even if not enabled), it tries to load these dependencies... If they are not installed, then we get these warnings...Why does installing the packages fix it?
By installing
import-in-the-middleandrequire-in-the-middleas dev dependencies, Sentry finds them and the warnings disappear. This is a safe workaround for local/dev, and does not affect production.Loading Sentry conditionally
One way to avoid these warningsβ οΈ is by loading Sentry conditionally. That is the approach I took in an earlier PR. However I realised that it would have to apply to any file importing Sentry:
which would end quite messy and affecting a lot of files. I realised installing the packages is just simpler ( they won't in the bundle or affect page load ) and using
enabledin the Sentry initialisation is also cleaner.Checklist π
For code changes:
--turbo)