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 adds support support for the nextjs `assetPrefix` option to the nextjs SDK. Currently, if users set this option, it changes the filepaths in their client-side stacktraces in a way not reflected in their release artifact names, causing sourcemaps not to work. This fixes that by using `RewriteFrames` to modify the stacktrace filepaths so that they'll match the release artifacts.
Notes:
- Initial work on this was done by @tomas-c in #6241. (Thanks, @tomas-c!) The approach taken there was to change the way the client-side release artifacts are named, rather than to change the filenames in the stacktrace as is done here. After discussions with @lforst, I decided to take this approach because it's more consistent with what we already do on the server side. There, we use `RewriteFrames`, and we mutate the filepaths to start with `app:///_next`. This mirrors that for the client side.
- In the process of working on this, I discovered that we currently have a bug, caused by the way we handle the `basePath` option when naming release artifacts, including it at the beginning of all artifact names. Unfortunately, it's not included in stacktrace filenames, so this is a mistake.
On the server side, this makes the stacktrace filenames and the artifact filenames not match, meaning sourcemaps for people using that option are currently broken for all sever-side errors. (The reason this hasn't been more obvious is that in the node SDK, we harvest context lines at capture time, rather than relying on sourcemapping to provide them. Also, server-side built code is transpiled but not bundled or mangled, making even un-sourcemapped code much easier to read than it is on the browser side of things.)
On the browser side, it doesn't break sourcemaps, but only because it turns out that nextjs copies `basePath` over into `assetPrefix` if a user provides the former but not the latter. As mentioned, `basePath` doesn't appear in stacktrace filepaths, but `assetPrefix` does, which is what led us to think was working.
To fix this, this PR stops including `basePath` in artifact filenames. As a result, on both the server-side and client-side, all artifact filenames are now of the form `~/_next/...`, rather than some looking like that but others looking like `~/basePathValue/_next/...`.
- Part of the work here was figuring out how `distDir`, `basePath`, and `assetPrefix` interact, and where they show up in stacktrace filepaths. Just so it's written down somewhere, the answer is:
- `basePath` - Never shows up in stacktrace filepaths, except insofar as it's copied into `assetPrefix` if it's set and `assetPrefix` isn't, in which case `assetPrefix` acts like it's path-only.
- `distDir` - Server-side stacktrace filepaths are of the form `<pathToProjectDir>/<distDir>/server/...` (or `<pathToProjectDir>/<distDir>/serverless/...`). Example: `/path/on/host/machine/someDistDir/server/...`.
- `assetPrefix` - If `assetPrefix` is a full url, client-side stacktrace filepaths are of the form `<assetPrefixHost>/<assetPrefixPath>/_next/static/...`. If `assetPrefix` just a path, stacktrace filepaths are of the form `<host>/<assetPrefixPath>/_next/static/...`. Examples: http://some.assetPrefix.host/some/assetPrefix/path/_next/...` and `http://some.normal.domain/some/assetPrefix/path/_next/...`.
Fixes#4174.
0 commit comments