I honestly thought I’d seen every way a Webpack configuration could spiral out of control. Between custom Babel transforms and race conditions in dependency extraction, the “standard” WordPress build pipeline has become a maintenance nightmare for large-scale projects. However, a significant shift is coming. The introduction of @wordpress/build marks a move away from the flexible but bloated Webpack era toward a convention-based, high-performance engine powered by esbuild.
The Complexity Debt of wp-scripts
For years, @wordpress/scripts was the gold standard. It wrapped Webpack and Babel into a digestible package, but it came with a heavy cost. Specifically, it was designed as a thin wrapper that prioritized flexibility over speed. If you were building a simple block, it worked fine. But if you were managing a monorepo or a plugin with dozens of entry points, you were likely staring at a build process that took minutes instead of seconds.
Consequently, even Gutenberg itself didn’t use the standard wp-scripts for its own core packages. It relied on a custom internal pipeline because the public tooling simply couldn’t handle the scale. @wordpress/build is the effort to bridge that gap, absorbing the complexity into the tool itself so we can stop writing boilerplate and start shipping code.
@wordpress/build: Convention Over Configuration
The most radical change in this new tooling is the philosophy of discovery. Instead of defining entry points in a JavaScript file, @wordpress/build uses fixed folder conventions. If you place code in packages/, routes/, or the proposed blocks/ directory, the tool finds it automatically. No Webpack config, no manual entry list, and no headache.
{
"wpPlugin": {
"name": "my-awesome-plugin",
"scriptGlobal": "acme",
"packageNamespace": "acme-namespace",
"handlePrefix": "acme"
}
}Furthermore, this configuration in your package.json replaces dozens of lines of PHP and Webpack settings. It defines how your scripts are externalized and how they interact with other plugins in the ecosystem. It’s a cleaner, more architecturally sound approach than the “thin wrapper” model we’ve used for the last five years.
No More Manual PHP Registration
One of the biggest bottlenecks in WordPress development is the disconnect between JS and PHP. You build your script, then you have to remember to wp_enqueue_script it with the correct dependencies from your .asset.php file. It’s manual, it’s error-prone, and it’s legacy thinking. @wordpress/build automates this entire layer.
<?php
// bbioon_load_generated_registration
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';
By requiring a single generated file, your plugin automatically hooks into wp_default_scripts and wp_default_styles. It handles script modules, static vs. dynamic imports, and even RTL styles without you lifting a finger. This is the kind of developer experience we’ve been begging for since Gutenberg’s early days.
The esbuild Advantage
Under the hood, the shift from Webpack to esbuild (a bundler written in Go) is a game-changer. For a project with 100+ packages, a full build that previously took minutes now takes seconds. Incremental rebuilds in watch mode are near-instant. If you’ve ever felt your productivity tank while waiting for a Webpack dev server to reload, you’ll realize why this transition is necessary.
Look, if this @wordpress/build stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Roadmap to Stability
Currently, @wordpress/build is the internal engine for Gutenberg, and while it’s powerful, it still has some rough edges for standalone plugins. In contrast to wp-scripts, the API is still being shaped. If you are building complex monorepos or multiple interoperable plugins, now is the time to engage with the vision on GitHub. For everyone else, stay the course on your current stable setup—the benefits of this speed and automation will eventually flow down to wp-scripts as the two projects converge.
