ref(nextjs): Use resolved paths for require calls in config code

[lobsterkatie]

Currently, we use relative paths for the require calls in syncPluginVersionWithNextVersion. Though this works most of the time, it depends on the particular structure of the user's node_modules directory, which is mostly predictable but not guaranteed. This PR therefore switches to using a combination of require.resolve and a recursive search up the file hierarchy to find the package.json files we need.

Fixes #3424.
Fixes #3430.

[github-actions]

size-limit report

Path	Size
@sentry/browser - CDN Bundle (gzipped)	20.61 KB (0%)
@sentry/browser - Webpack	21.49 KB (0%)
@sentry/react - Webpack	21.53 KB (0%)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped)	27.91 KB (+0.01% 🔺)

[dcramer]

Will this not still expect everything to live at the project's node_modules path? vs node_modules/@sentry/nextjs/node_modules?

ideally it would just replicate npm's resolver code to find the other module

[lobsterkatie]

@dcramer - fair point. As it turns out to be more complicated than one might like, I'm going to outsource the task.

[dcramer]

this is super off topic, but something we might want to consider.. given complexity of vulnerabiltiies/deps in sdks.

what if we vendored third party deps? im assuming (and praying) we have very few, and it'd make everyone more comfortable knowing the dep graph isnt 1000+ random npm modules that might change under the hood and cause customers more security vetting

[lobsterkatie]

@dcramer It's funny you should say that... The library I linked above turns out to be non-ESM compliant (export = ...), which breaks our build, and so as a stopgap I just copied the transpiled JS over to our nextjs package and figured we'd just vendor it until it got fixed. (I haven't pushed it yet because I'm fighting with TS at the moment.) Doing that as a permanent solution is another story, and I see real pros and cons there. Definitely something to think about, though.

[Tevinthuku]

@lobsterkatie ,Will using resolve-package-path as you mentioned help in getting the package location in a yarn-workspace setup where the packages are hoisted?
....

I think it's best if I create an issue with the exact problem that Im facing . Done #3430

[lobsterkatie]

@Tevinthuku Yes, I believe it should, though I didn't end up using that library, as it's broken for ESM builds (see my note above), and vendoring it turned out to be more trouble than it was worth.

Once this is merged and released, which should be in the next few days, please let me know if you're still having trouble.

[HazAT]

Can we also fix this: #3441 ?

[iker-barriocanal]

Can we also fix this: #3441 ?

Addressing it here: #3444

[lobsterkatie]

Can we also fix this: #3441 ?

Addressing it here: #3444

I think #3444 fixes only part of #3441 - it will stop sentry problems from turning into breaking-the-world problems, but it doesn't address the read-only nature of the vercel filesystem. In other words, we won't crash people's apps, but the plugin won't work, either. Still I think it's a good thing to do, and we can address the read-only part in a separate PR.

[Tevinthuku]

I got to test the new release of the plugin & Im getting this error,

This line is the culprit,

sentry-javascript/packages/next-plugin-sentry/src/on-init-client.js

Line 1 in e5a1771

import '../../../../sentry.client.config.js';

I tried commenting it out locally to see what happens & the same error occurs, but now on the on-init-server.js file.

[lobsterkatie]

@Tevinthuku -Thanks. Can you please file an issue with pretty much exactly what you have in your comment? I'll work on a fix in the meantime.

[Tevinthuku]

Sure thing.
Done #3452