Worker entry points are built in a non-repeatable manner

[desrosj]

Description

While looking into discrepancies between local builds of https://github.com/WordPress/wordpress-develop/ and the corresponding commit on https://github.com/wordPress/wordpress, I noticed that there were unexplained changes to the hash values calculated based on the contents of the corresponding files.

It seems that when wp-build compiles files, it's including the absolute path of the file in the // wasm-inline: comment, which will vary based on OS and location of the repository within the filesystem when the build script is run. The hash is then generated from the full contents of the file, including the path noted within the inline comment. This makes each build non-reproducible.

Non-reproducible builds can result in unnecessary code churn and inconsistent build script results, which makes it difficult to validate build tool-related changes do not have unexpected outcomes.

Step-by-step reproduction instructions

You can reproduce the problem with the following steps:

• Clone gutenberg twice into two different paths (ie. gutenberg-one, gutenberg-two.
• Run npm install && npm run build in both.
• Run the following commands:

git diff --no-index \
  /path/to/repo/gutenberg-a/build/modules/vips/worker.min.js \
  /path/to/repo/gutenberg-b/build/modules/vips/worker.min.js

git diff --no-index \
  /path/to/repo/gutenberg-a/build/modules/vips/worker.min.asset.php \
  /path/to/repo/gutenberg-b/build/modules/vips/worker.min.asset.php

Notice the differences in build output despite source files being exactly the same. Note: git diff --no-index /path/to/gutenberg-one/build /path/to/gutenberg-two/build will also work. But there will be many more files without including the fix from #76098.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[adamsilverstein]

It seems that when wp-build compiles files, it's including the absolute path of the file in the // wasm-inline: comment,

where do you see this, in the diff?

The wasm is inlined in this step, maybe this is introducing the absolute path you mentioned?

gutenberg/packages/wp-build/lib/build.mjs

Lines 255 to 294 in ff51a79

	const wasmInlinePlugin = {
	name: 'wasm-inline',
	setup( build ) {
	// Resolve .wasm imports from node_modules.
	build.onResolve( { filter: /\.wasm$/ }, async ( args ) => {
	// Handle imports like 'wasm-vips/vips.wasm'.
	if ( ! args.path.startsWith( '.' ) ) {
	const { createRequire } = await import( 'module' );
	const require = createRequire( args.resolveDir + '/index.js' );
	try {
	const resolved = require.resolve( args.path );
	return {
	path: resolved,
	namespace: 'wasm-inline',
	};
	} catch {
	// If resolution fails, let other plugins handle it.
	return null;
	}
	}
	return null;
	} );
	// Load WASM files and convert to base64 data URLs.
	build.onLoad(
	{ filter: /.*/, namespace: 'wasm-inline' },
	async ( args ) => {
	const wasmBuffer = await readFile( args.path );
	const base64 = wasmBuffer.toString( 'base64' );
	const dataUrl = `data:application/wasm;base64,${ base64 }`;
	return {
	contents: `export default "${ dataUrl }";`,
	loader: 'js',
	};
	}
	);
	},
	};

[desrosj]

@adamsilverstein I think that #76113 should take care of this.