chore(nextjs): Remove require
call on TypeScript file
#4498
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.
As part of server start-up on nextjs, we instrument various server methods for tracing, in a module called (appropriately enough)
instrumentServer
. Because even importing theinstrumentServer
module can throw errors in certain situations (during build, or in Next 12 on Vercel), the JS version of the module (which is what will exist at runtime) is conditionally required rather than imported at the top of the index file.Just for safety, that dynamic
require
is wrapped in atry-catch
. Currently, in the catch block exists a fallback attempt to require the TS version of the module:sentry-javascript/packages/nextjs/src/index.server.ts
Lines 137 to 151 in ad37109
This causes warnings in Next 12. Since there's no logical or replicable way to have the JS
require
fail but the TSrequire
work (in spite of the comment, tests do not actually trigger this), and since no one can recall* why it's in there in the first place, this PR removes it, thus preventing the warnings.*Careful readers will notice that the PR which introduced this code was, as it turns out, authored by me. The reason I don't know why it's there in spite of that fact is because it was added by someone else, who then merged the PR.
Note: I thought it was worthwhile to log a warning when instrumenting the server fails, so I added that back in. It doesn't have the debug-build guard the way all other log statements currently do, but that's because the debug-build build process will have changed by the time it's relevant (in v7).