Build: Move the build tool to a dedicated package #72743
Merged
Conversation
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
youknowriad
added
the
[Type] Build Tooling
youknowriad
requested review from
ajitbohra,
fabiankaegy,
juanmaguitar and
nerrad
as code owners
|
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. |
Contributor
Author
|
@fabiankaegy Would love some thoughts / testing when you have time. |
|
Size Change: 0 B Total Size: 2.37 MB ℹ️ View Unchanged
|
youknowriad
force-pushed
the
add/build-tool-package
branch
from
7305904 to
034c803
Compare
|
Flaky tests detected in c701079. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18882004794
|
youknowriad
force-pushed
the
add/build-tool-package
branch
from
034c803 to
831f4a1
Compare
Member
|
Hey @youknowriad 👋 This is exciting! Will definitely give this a go this week! Question from just glancing through the code 🤔 Will all scripts that are automatically enqueued through this be enqueued globally or what's the plan for more granular control over where / when a script should load? 🤔 |
Contributor
Author
This doesn't handle script enqueing at the moment. Only registration. |
aduth
reviewed
Oct 28, 2025
| // Step 7: Build packages | ||
| console.log( '\n📦 Building packages (production mode)...' ); | ||
| await exec( 'node', [ './bin/packages/build.mjs' ], { | ||
| await exec( 'wp-build', [], { |
Member
There was a problem hiding this comment.
I'm surprised this doesn't need to be executed through npm exec / npx ? How is wp-build on the PATH ?
Contributor
Author
There was a problem hiding this comment.
My guess is that since it's a dependency in the root package.json it gets added to the "bin" folder in node_modules which is in the path when run through npm scripts?
Member
There was a problem hiding this comment.
Hm, you're probably right about that, but it also means we can't run the file directly. I'm not sure about this script, but I've been running bin/packages/build.mjs directly to help keep a tight feedback loop with changes on it.
Not a deal-breaker.
Member
There was a problem hiding this comment.
Should this folder be named build? For alignment to packages/[folder-name] directory placement -> @wordpress/[folder-name] package name. Also similar to wp-env being in packages/env.
Contributor
Author
There was a problem hiding this comment.
The reason I did that is to avoid conflicts with global .gitignore build folder. Granted an exception is possible but I was hesitant.
Member
There was a problem hiding this comment.
Yeah I can see that being tricky, not only with .gitignore, but other configurations which target build directory patterns (e.g. linter ignore patterns). Doesn't feel great and I think we could manage with the exceptions, but it'll probably be a nuisance if we did.
Contributor
Author
|
One thing I realized is that this build tool assumes all wpScript: true package should result in |
aduth
approved these changes
Oct 28, 2025
| ); | ||
|
|
||
| console.log( '\n📄 Generating PHP registration files...\n' ); | ||
| const phpReplacements = await getPhpReplacements( ROOT_DIR ); |
Member
There was a problem hiding this comment.
To my comment at #72740 (comment) , did you move it here because it's async ? I think it's okay, though passing around the arguments is pretty noisy.
Alternatively:
- Top-level async could be okay, though it might add some delay to the initial import (okay if we expect it'll be used)
- The top-level constant could be a shared promise value that's referenced in the individual functions
Contributor
Author
There was a problem hiding this comment.
Yes, mostly because of the async.
Contributor
Author
There was a problem hiding this comment.
I agree it's a bit noisy but I'm also not fully convinced about the alternatives.
| } | ||
| const resolved = import.meta.resolve( `${ fullPackageName }/package.json` ); | ||
| const result = getPackageInfoFromFile( fileURLToPath( resolved ) ); | ||
| packageJsonCache.set( fullPackageName, result ); |
Member
There was a problem hiding this comment.
This cache kinda feels unnecessary? What's the bottleneck if we don't have this cache? import.meta.resolve ?
Contributor
Author
There was a problem hiding this comment.
yes, my assumption is that node resolution is probably a bit expensive.
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.
Refs #72032
What?
Really excited about this PR, it brings the build tool that we iterated on lately to a new dedicated
@wordpress/buildscripts that plugins would be able to use to have their own scripts, modules and styles registered automatically.We're not going to get everything working perfectly from the start but we're going to need feedback to make it work. We're going to need a lot of docs as well but the README already has some light doc.
Testing Instructions
npm linkto use the package before it's published)