@wordpress/build — The Next Generation of WordPress Plugin Build Tooling

[bph]

Discussed in #453

^{Originally posted by juanmaguitar February 25, 2026}
WordPress has long relied on @wordpress/scripts as its opinionated build toolchain for plugin and block development. But @wordpress/scripts quietly accumulated complexity — a webpack dependency, custom Babel plugins, and a disconnect between how the community builds plugins and how Gutenberg itself builds its packages internally. @wordpress/build is the answer to that disconnect: an esbuild-based, zero-config build system that auto-generates PHP registration files, understands the @wordpress/* namespace natively, and is explicitly designed to become the engine underneath @wordpress/scripts itself.

This article would introduce @wordpress/build to the developer community — explaining the vision behind it, showing how it works in practice, and helping developers understand when and how to start using it.

Key Points for the Article

• The problem with @wordpress/scripts today: Gutenberg internally never used @wordpress/scripts for its own packages — it relied on separate custom tooling. That gap is what @wordpress/build closes.
• The vision (issue #72032): A single wp-build command, no arguments, no config files — the tool auto-discovers what needs to be built from the folder structure and package.json conventions.
• esbuild vs webpack: Why the switch matters — build times go from minutes to seconds for large plugin codebases.
• Auto-generated PHP: Instead of manually writing wp_register_script(), @wordpress/build generates a complete build/build.php registration file. Show what it generates and how to include it.
• The wpPlugin namespace model: How to configure your plugin's global (window.myPlugin.*), handle prefix, and how @wordpress/* and third-party namespaces (WooCommerce, etc.) are automatically externalized.
• The convergence roadmap: @wordpress/build is not just an alternative — it's planned to replace the build engine inside @wordpress/scripts, with a backwards-compatible migration path and deprecation of the webpack/babel stack.
• When to adopt it today: Practical guidance on who should try it now (monorepo plugin projects, Gutenberg contributors) vs who should wait (single-block plugins using @wordpress/create-block).

References

• @wordpress/build package
• Issue #72032 — "WordPress Scripts: A vision for a v2 version" by Riad Benguella
• PR #72743 — initial implementation
• @wordpress/scripts docs

Audience

WordPress plugin developers building JS-heavy plugins, developers maintaining multi-package plugin monorepos, Gutenberg contributors, and anyone currently using @wordpress/scripts who wants to understand where the toolchain is heading.

[!Note]
This article could be well-timed as a "here's what's coming" piece — @wordpress/build is functional but explicitly seeking third-party feedback (Riad's words: "I can't find edge cases by only working on Gutenberg"). Publishing this could drive real adoption and feedback while the API is still malleable.