Ensure consistent, repeatable build results when inlining WASM files via wasmInlinePlugin #76113
Merged
Ensure consistent, repeatable build results when inlining WASM files via wasmInlinePlugin #76113
wasmInlinePlugin #76113Conversation
This adds `sourceMap: false` to `sassPlugin` calls to prevent scenarios where CSS builds are inconsistent and non-reproducible due to the fact that `esbuild-sass-plugin` uses absolute paths when creating the `sourceMappingURLs` included in generated CSS. The `wp-build` package creates a hash of each CSS file to serve as a value of the `data-wp-hash` attribute. While `/*# sourceMappingURL=... */` is stripped out of the built CSS files, this is handled by `postcss` after the hash is generated from the file's contents. Instead of relying on `postcss` to strip source maps out at the end, `sourceMap: false` ensures it's never included. This results in consistent hash generation when the file contents are unchanged regardless of where the repository is cloned or which operating system is being used.
This updates the `wasmInlinePlugin` to use normalized relative paths instead of absolute ones. Because `esbuild` places the `path` within an inline comment, including the full absolute path causes inconsistent hashes to be calculated.
desrosj
requested review from
Copilot,
dmsnell,
jsnajdr,
peterwilsoncc and
youknowriad
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
desrosj
added
[Type] Bug
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves build reproducibility in @wordpress/wp-build by ensuring the wasmInlinePlugin no longer embeds absolute filesystem paths in generated output, which previously caused inconsistent hashes across different clone locations.
Changes:
- Update
wasmInlinePluginto return a normalized path relative toROOT_DIRfromonResolve(instead of an absolute path). - Preserve the absolute resolved WASM path in
pluginDatasoonLoadcan still reliably read the file from disk.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
8 tasks
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 7.0 Editor Tasks
|
Size Change: -28 B (0%) Total Size: 6.87 MB
ℹ️ View Unchanged
|
This was referenced Mar 4, 2026
adamsilverstein
approved these changes
Mar 4, 2026
Member
adamsilverstein
left a comment
adamsilverstein
left a comment
There was a problem hiding this comment.
Looks good to me. would be good to confirm manually that inlining still works as expected.
Member
|
Just some linter errors to fix. |
Member
Author
|
@adamsilverstein did you get to test this yesterday by chance? |
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
desrosj
added
the
Backport to WP 7.0 Beta/RC
|
Flaky tests detected in fa47383. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22744664297
|
peterwilsoncc
approved these changes
Mar 6, 2026
Contributor
There was a problem hiding this comment.
@desrosj I've taken the liberty of merging in trunk to aid with testing.
This tests well to me and is working as expected.
Testing notes:
- Checkout two copies of the repo side by side
- Run
npm i; npm run buildin each - Run
git diff --no-index --compact-summary ./gb-one/build ./gb-two/build - Observe difference described above
- Run
git checkout fix/non-repeatable-wasm-builds; npm run buildin each checkout - Run
git diff --no-index --compact-summary ./gb-one/build ./gb-two/build - Observe the builds are now deterministic
This will need backporting to the wp/7.0 branch to resolve issues in the core ticket.
Trunk
./{gb-one => gb-two}/build/modules/vips/worker.js | 2 +-
./{gb-one => gb-two}/build/modules/vips/worker.js.map | 2 +-
./{gb-one => gb-two}/build/modules/vips/worker.min.asset.php | 2 +-
./{gb-one => gb-two}/build/modules/vips/worker.min.js | 4 ++--
./{gb-one => gb-two}/build/modules/vips/worker.min.js.map | 2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
Feature branch
I think this is good to go but am having trouble confirming that client side media is working as expected. I'm not sure if that's because I am using the wrong browser or it's due to another form of PEBKAC.
Member
Author
|
I'm reasonably confident in this one, so I'm going to merge. Thanks, all! |
github-project-automation
bot
moved this from 🔎 Needs Review
to ✅ Done
in WordPress 7.0 Editor Tasks
github-actions
bot
removed
the
Backport to WP 7.0 Beta/RC
gutenbergplugin
pushed a commit
that referenced
this pull request
Mar 10, 2026
…via `wasmInlinePlugin` (#76113) * Prevent non-reproducible Sass/CSS builds. This adds `sourceMap: false` to `sassPlugin` calls to prevent scenarios where CSS builds are inconsistent and non-reproducible due to the fact that `esbuild-sass-plugin` uses absolute paths when creating the `sourceMappingURLs` included in generated CSS. The `wp-build` package creates a hash of each CSS file to serve as a value of the `data-wp-hash` attribute. While `/*# sourceMappingURL=... */` is stripped out of the built CSS files, this is handled by `postcss` after the hash is generated from the file's contents. Instead of relying on `postcss` to strip source maps out at the end, `sourceMap: false` ensures it's never included. This results in consistent hash generation when the file contents are unchanged regardless of where the repository is cloned or which operating system is being used. * Avoid using absolute paths for Wasm files. This updates the `wasmInlinePlugin` to use normalized relative paths instead of absolute ones. Because `esbuild` places the `path` within an inline comment, including the full absolute path causes inconsistent hashes to be calculated. * Fix alignment issues. --------- Co-authored-by: desrosj <desrosj@git.wordpress.org> Co-authored-by: peterwilsoncc <peterwilsoncc@git.wordpress.org> Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
github-actions
bot
added
the
Backported to WP Core
|
I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: 654c461 |
pento
pushed a commit
to WordPress/wordpress-develop
that referenced
this pull request
Mar 10, 2026
This updates the pinned hash from the `gutenberg` from `7b7fa2bc97a8029a302bd6511cf0d206b5953172` to `9b8144036fa5faf75de43d4502ff9809fcf689ad`. The following changes are included: - Use V2 Yjs methods for HTTP Polling (WordPress/gutenberg#76304) - Plugin: Include Icons assets in ZIP (WordPress/gutenberg#75866) - Ensure consistent, repeatable build results when inlining WASM files via `wasmInlinePlugin` (WordPress/gutenberg#76113) - Account `IS_WORDPRESS_CORE` is set. (WordPress/gutenberg#76334) - Block Visibility: Add `fetchpriority=auto` to `IMG` tags in blocks with conditional viewport visibility to prevent potential erroneous high loading priority (WordPress/gutenberg#76302) A full list of changes can be found on GitHub: https://github.com/WordPress/gutenberg/compare/7b7fa2bc97a8029a302bd6511cf0d206b5953172…9b8144036fa5faf75de43d4502ff9809fcf689ad. See #64595, #64393. git-svn-id: https://develop.svn.wordpress.org/trunk@61870 602fd350-edb4-49c9-b593-d223f7449a82
markjaquith
pushed a commit
to markjaquith/WordPress
that referenced
this pull request
Mar 10, 2026
This updates the pinned hash from the `gutenberg` from `7b7fa2bc97a8029a302bd6511cf0d206b5953172` to `9b8144036fa5faf75de43d4502ff9809fcf689ad`. The following changes are included: - Use V2 Yjs methods for HTTP Polling (WordPress/gutenberg#76304) - Plugin: Include Icons assets in ZIP (WordPress/gutenberg#75866) - Ensure consistent, repeatable build results when inlining WASM files via `wasmInlinePlugin` (WordPress/gutenberg#76113) - Account `IS_WORDPRESS_CORE` is set. (WordPress/gutenberg#76334) - Block Visibility: Add `fetchpriority=auto` to `IMG` tags in blocks with conditional viewport visibility to prevent potential erroneous high loading priority (WordPress/gutenberg#76302) A full list of changes can be found on GitHub: https://github.com/WordPress/gutenberg/compare/7b7fa2bc97a8029a302bd6511cf0d206b5953172…9b8144036fa5faf75de43d4502ff9809fcf689ad. See #64595, #64393. Built from https://develop.svn.wordpress.org/trunk@61870 git-svn-id: http://core.svn.wordpress.org/trunk@61157 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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.
What?
This updates the
wasmInlinePluginto use normalized relative paths instead of absolute ones.Closes #76112. Related to #76098.
Why?
Because
esbuildplaces the full absolute path within an inline comment, the build script calculates inconsistent hashes resulting in unexpected changes.How?
This switches from an absolute path to a normalized one relative to the repository's root directory.
Testing Instructions
gutenberg-one,gutenberg-two.npm install && npm run buildin both.There will be changes present before applying this PR. After there should be no changes to these files.