Skip to content

Conversation

@timfish
Copy link
Contributor

@timfish timfish commented Nov 8, 2024

What kind of change does this PR introduce?

Adds support to SourceMapDevToolPlugin for injecting debug IDs into source files and sourcemaps as per the TC39 proposal.

  • Sentry users have been relying on debug ids in production for a number of years. Sentry process hundreds of millions of files per month containing debug ids!
  • A Github search suggests debug ids are also used by Backtrace and Expo
  • Bun added debug id injection to it's bundler when they added sourcemap support
  • Rolldown added support in v0.14.0
  • Rollup added support in v4.25.0

Did you add tests for your changes?

Not yet but will add them if this is likely to get merged!

Does this PR introduce a breaking change?

No

What needs to be documented once your changes are merged?

I guess the SourceMapDevToolPlugin docs need updating?

Ideally I would like this option to be accessible from the top-level webpack config. I toyed with the idea of adding it to the devtool option (ie. hidden-source-map-debug-ids) but this option already contains a lot of different combinations of options.

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Nov 8, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

@webpack-bot
Copy link
Contributor

webpack-bot commented Nov 8, 2024

For maintainers only:

  • This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
  • This needs to be backported to webpack 4 (issue will be created when merged)

.update(source)
.digest("hex");
// The next 64 bits is a hash of the filename and sourceHash
const hash128 = `${sourceHash}${createHash("xxhash64")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same for sourceHash and respect other options, like https://webpack.js.org/configuration/output/#outputhashsalt

Copy link
Contributor Author

@timfish timfish Nov 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to not just use a specific (maybe the fastest) hash here?

The code relies on getting a specific number of hex characters and if users pass a custom hashFunction, will it always return 16 hex characters?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason to not just use a specific (maybe the fastest) hash here?

maybe people want to change the logic depending on the options provided

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the hashFunction can now be a constructor to a custom hash function. You can provide a non-crypto hash function for performance reasons.

My understanding is that users can supply a custom hashFunction if they want to change the way webpack generates file name hashes.

For Debug IDs we almost certainly don't want users to be able to configure the hash function. According to the spec, Debug ids should be a uuid derived from a deterministic hash of the file source code. The hash type isn't defined in the spec but it should be deterministic and it should have enough entropy that it is effectively unique. If we allow users to configure the hash function, the debug IDs may no longer meet the spec.

In the PR code, the 128bit debug ID is created from two xxhash64 hashes and on my machine it does this with a 300kB bundle in 2 milliseconds.

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good for me, let's add

const noSources = options.devtool.includes("debugids");

here
https://github.com/webpack/webpack/blob/main/lib/WebpackOptionsApply.js#L266 and enable this option

@timfish
Copy link
Contributor Author

timfish commented Nov 14, 2024

I've added a test case which tests the devtool addition so it will show full coverage but it should probably also be testing that the debugid magic comments are actually in the source and there is a matching entry in the sourcemaps.

Any pointers of how I can add this to the test case?

@alexander-akait
Copy link
Member

You can add it here - You can add them here - https://github.com/webpack/webpack/tree/main/test/configCases/source-map

@timfish timfish marked this pull request as ready for review November 14, 2024 14:01
@alexander-akait
Copy link
Member

@timfish Sorry, can you rebase? I want to merge it for the next release, thank you

@timfish
Copy link
Contributor Author

timfish commented Nov 20, 2024

can you rebase?

Yes, will do this in a few hours when I'm off the awful plane wifi!

@timfish
Copy link
Contributor Author

timfish commented Nov 20, 2024

Right, should be good to go!

@alexander-akait alexander-akait merged commit e47a3a3 into webpack:main Nov 21, 2024
49 of 56 checks passed
@alexander-akait
Copy link
Member

Thanks

@webpack-bot
Copy link
Contributor

I've created an issue to document this in webpack/webpack.js.org.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants