Repository navigation
Conversation
Contributor
Optional E2E testsAll optional checks were successful. 9 successful. See the run. Successful checks
|
Contributor
size-limit report 📦Compared: bf8f4d3 (PR test merge using develop at 9279303) Against: 9279303 (develop) · base run #66015 ✅ Baseline matches: this diff contains only this PR's changes.
|
timfish
force-pushed
the
feat/nuxt-delete-sourcemaps-after-upload
branch
from
November 13, 2026 11:35
1bd66b9 to
48ccf3b
Compare
Base automatically changed from
feat/bundler-plugins-delete-without-upload
to
develop
November 13, 2026 13:49
…ead of a glob When the SDK enables hidden client source maps with the Vite builder and the user set neither `deleteSourcemapsAfterUpload` nor `filesToDeleteAfterUpload`, the client Vite plugin now gets `deleteSourcemapsAfterUpload: true` and `sdkEnabledSourceMaps` for the client build only. With the Vite environment API, the `ssr` and `nitro` environments get neither. The maps then never reach the build output. As before, this also holds when no upload runs and for chunks outside a user's `assets` or `ignore`. This replaces the client fallback glob, which deleted every map in the Nitro public dir. With the webpack or rspack builder no Vite plugin runs, so the public-dir glob stays. A user's `filesToDeleteAfterUpload` still replaces the SDK's deletion and runs in the Nitro build. The server side is unchanged.
timfish
force-pushed
the
feat/nuxt-delete-sourcemaps-after-upload
branch
from
November 13, 2026 13:53
48ccf3b to
e249657
Compare
timfish
marked this pull request as ready for review
November 13, 2026 17:36
javascript-sdk-gitflow
Bot
requested review from
chargome,
nicohrubec and
s1gr1d
November 13, 2026 17:37
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit e249657. Configure here.
| */ | ||
| function isClientEnvironment(environment: string | undefined): boolean { | ||
| return environment === undefined || environment === 'client'; | ||
| } |
There was a problem hiding this comment.
SSR maps can inherit client deletion
Medium Severity
isClientEnvironment treats a missing environment name as the client build, so the SDK default turns on deleteSourcemapsAfterUpload and sdkEnabledSourceMaps for that case. The Vite plugin always makes its shared * decision with no environment name, then uses that decision for every environment that did not have its own build.sourcemap in the config hook. Under the Vite environment API, ssr or nitro can therefore inherit client deletion and lose the SSR maps Nitro still needs. Previously deleteSourcemapsAfterUpload was always false, so that fallback did not remove maps.
Reviewed by Cursor Bugbot for commit e249657. Configure here.
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
When the Nuxt SDK turns on hidden client source maps with the Vite builder and the user set neither
deleteSourcemapsAfterUploadnorfilesToDeleteAfterUpload, it now passesdeleteSourcemapsAfterUpload: trueandsdkEnabledSourceMapsto the client Vite plugin instead of deleting the maps later with a glob. Both apply to the client build only: with the Vite environment API (Nuxt 5, or Nuxt 4 withexperimental.viteEnvironmentApi) thessrandnitroenvironments get neither, so the plugin does not change their settings. The plugin never writes those maps to the build output. As before, this also holds when no upload runs and for chunks that the user'sassetsorignoreleave out. The old glob deleted every*.mapin the Nitro public dir, including maps from the user'spublic/folder or other modules; the new code removes only the maps of the Vite client bundle. With the webpack or rspack builder no Vite plugin runs, so the SDK keeps the public-dir glob there. Withserver.builder: 'vite'(no Nitro) the SDK-enabled client maps are now removed, where the old glob never ran because it waited for Nitro. A user'sfilesToDeleteAfterUploadstill replaces the SDK's client deletion and runs in the Nitro build before Nitro lists its public files, so deleted maps return 404. The server side is unchanged because Nitro needs the SSR maps on disk.The Nuxt 4 and 5 source map apps get a no-upload variant that asserts no client maps and no
sourceMappingURLcomments in the public output, and the Nuxt 5 app gets a variant where Sentry turns the client maps on and uploads them. The Nuxt 4 app now records chunks without a map during the build, because maps the SDK turned on no longer reach.nuxt/dist/client. Thenuxt-5-sourcemapsapp is optional in CI, so its variants were run locally.