automated review: Make Debug IDs deterministic. Both Sentry tools derive the ID from content: Metro uses md5 of the bundle, and the webpack plugin uses stringToUUID(chunk.contentHash.javascript ?? chunk.hash). Random UUIDs make builds non-reproducible and give identical bundles different IDs.

+1 on deriving from content. One trap worth flagging for whoever picks this up: the two comments here are really one bug (content-derived IDs delete both the map and the staleness class), but a content hash taken after injection is circular — the banner contains the ID, so the hash depends on its own output.

Upstream avoids that by deriving from the pre-injection hash, which is also why they inject at processAssets ADDITIONS instead of through BannerPlugin. So this is the right direction, but it's closer to moving injection into processAssets than to swapping randomUUID() for a hash.

automated review: debugIdsByChunk lives for the whole compiler and is never reset between compilations. In watch mode, a rebuilt chunk keeps its old ID even when its content changes. A content-derived ID (see the other comment) removes the need for this map.

automated review: Also emit the //# debugId=<id> comment, before //# sourceMappingURL if present. Metro's serializer, @sentry/webpack-plugin and the community Re.Pack plugin all do this. sentry-cli uses it to pair bundle and map, which matters for JSC builds and for uploads outside the Gradle/Xcode scripts.

automated review: Skip in development (non-production mode or dev server) instead of leaving it to the docs. createSentryMetroSerializer returns early for dev/hot builds.

automated review: PROCESS_ASSETS_STAGE_REPORT runs after real content hashing, so the map is changed after its hash is computed. Sentry uses PROCESS_ASSETS_STAGE_DEV_TOOLING + 1, right after source map generation, so later stages see the final assets. Consider doing the same.

automated review: Coverage is single-entry only. Please add:

• multiple chunks: each gets a distinct ID that matches its own map
• the dev-mode skip
• the //# debugId= comment, if added
• a deterministic ID when building the same input twice

Two more worth adding to this list:

• a webpack-as-compiler case, since CI only exercises rspack. The plugin does work under real webpack 5.105.4 — I ran it with SourceMapPlugin present and the map came out stamped and correctly paired — but nothing guards that today, and the dual-compiler support is the whole reason apply is typed the way it is.
• one that goes through the package entry (Repack.plugins.SentryDebugIdPlugin) rather than importing the class directly, so the documented import path is actually covered.

The JSDoc example and the docs page (sentry-debug-id.md) both show new Repack.SentryDebugIdPlugin(), but that isn't a valid import — src/index.ts:2 is export * as plugins from './plugins/index.js', so only RepackPlugin is re-exported at the top level.

I ran it against a real project and it fails at config load:

error Repack.SentryDebugIdPlugin is not a constructor.
    at file:///…/rspack.config.mjs:61:22
    at async loadProjectConfig (…/dist/commands/common/config/loadProjectConfig.js:42:14)

new Repack.plugins.SentryDebugIdPlugin() works and builds. That also matches the convention the other plugin docs already use — hermes-bytecode.md:28 and code-signing.md:12 both say Repack.plugins.*.

Please fix the example here and the usage snippet in the docs page. It would also be worth one test that imports through the package entry rather than constructing the class directly — right now the public surface is completely untested, which is why this slipped through.

stats.hasErrors() is never checked here, so if the compilation itself fails the test doesn't report the build error — it fails later on readFileSync with a confusing ENOENT for a file that was never written. Worth checking stats.hasErrors() and rejecting with the real message first.

+1 on deriving from content. One trap worth flagging for whoever picks this up: the two comments here are really one bug (content-derived IDs delete both the map and the staleness class), but a content hash taken after injection is circular — the banner contains the ID, so the hash depends on its own output.

Upstream avoids that by deriving from the pre-injection hash, which is also why they inject at processAssets ADDITIONS instead of through BannerPlugin. So this is the right direction, but it's closer to moving injection into processAssets than to swapping randomUUID() for a hash.

Two more worth adding to this list:

• a webpack-as-compiler case, since CI only exercises rspack. The plugin does work under real webpack 5.105.4 — I ran it with SourceMapPlugin present and the map came out stamped and correctly paired — but nothing guards that today, and the dual-compiler support is the whole reason apply is typed the way it is.
• one that goes through the package entry (Repack.plugins.SentryDebugIdPlugin) rather than importing the class directly, so the documented import path is actually covered.

The body of this snippet is verbatim from @sentry/bundler-plugin-core (var n=(new e.Error).stack;n&&(e._sentryDebugIds=…) — only the wrapper differs (;{try{…}} here vs their CodeInjection header/footer, !function(){try{…}}();).

The comment says "mirrors", which reads as reimplemented-from-scratch. A short source note here and in the changeset would be the honest thing, and it also gives future maintainers a pointer to diff against when Sentry changes the format.

Not blocking, just recording the cost, since source maps are the biggest asset in the build. Measured on a real release map:

Time is irrelevant; peak memory is the thing to keep an eye on — ~200MB transient per chunk, on top of a production build already close to node's heap limit. Fine to leave as is. If it ever matters, splicing "debugId":"…" into the JSON text avoids the parse/stringify round-trip entirely.