I thought I had seen every way a Webpack config can spiral out of control. Between custom Babel transforms and race conditions in dependency extraction, the standard WordPress build pipeline turned into something nobody wants to maintain on a large project. @wordpress/build is the replacement now taking shape: esbuild instead of Webpack, and folder conventions instead of configuration.
What wp-scripts costs you
@wordpress/scripts has been the default for years. It wraps Webpack and Babel so you do not have to, and it was built as a thin wrapper that chose flexibility over speed. For a single block that is a fine trade. For a monorepo, or a plugin with dozens of entry points, it means builds measured in minutes.
Gutenberg did not use wp-scripts for its own core packages. It ran a custom internal pipeline instead, because the public tooling could not handle that scale. That is the gap @wordpress/build is meant to close, by moving the complexity into the tool rather than into every plugin’s config.
@wordpress/build: convention over configuration
The biggest change is how entry points get found. You no longer list them in a JavaScript file. Put code in packages/, routes/, or the proposed blocks/ directory and the tool picks it up, which leaves no Webpack config and no entry list to keep in sync.
{
"wpPlugin": {
"name": "my-awesome-plugin",
"scriptGlobal": "acme",
"packageNamespace": "acme-namespace",
"handlePrefix": "acme"
}
}That block in your package.json replaces dozens of lines of PHP and Webpack settings. It sets how your scripts are externalized and how they interact with other plugins. Compared with the thin wrapper model of the last five years, there is far less of your own plumbing to get wrong.
No more manual PHP registration
The seam between JavaScript and PHP is where most of this goes wrong. You build the script, then you have to remember to wp_enqueue_script it with the right dependencies out of the .asset.php file. Forget one and you find out in the browser console. @wordpress/build generates that layer for you.
<?php
// bbioon_load_generated_registration
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';
Requiring that one generated file hooks your plugin into wp_default_scripts and wp_default_styles. It covers script modules, static and dynamic imports, and RTL styles. People have been asking for this since Gutenberg’s early days.
Why esbuild is faster
esbuild is written in Go, and the difference shows. On a project with more than 100 packages, a full build that used to take minutes finishes in seconds, and incremental rebuilds in watch mode are close to instant. Anyone who has sat watching a Webpack dev server reload knows what that time is worth.
If @wordpress/build is eating hours you would rather spend elsewhere, I can take it on. I have been working with WordPress since the 4.x days.
Should you switch yet
Right now @wordpress/build is Gutenberg’s internal engine, and it still has rough edges for standalone plugins. Its API is not settled the way wp-scripts is. If you maintain a monorepo or several plugins that have to work together, this is a good moment to weigh in on GitHub. Otherwise stay on the setup you have. The speed and the automation are expected to reach wp-scripts as the two projects converge.
