WordPress build tooling is about to change. But don’t worry, it’s not a disruptive rewrite that will break your existing workflows. If you’re using @wordpress/scripts today, you’ll likely continue using it as before. However, under the hood, the engine, philosophy, and developer experience are evolving.

The new player is @wordpress/build. A faster, convention-based build tool that replaces the webpack/Babel pipeline, auto-generates PHP registration files, and handles scripts, modules, and styles in a single pass. GutenbergGutenberg The block editor introduced in WordPress 5.0, usin... More already uses it internally. The long-term plan is for it to become the engine beneath @wordpress/scripts, meaning every pluginSoftware that adds specific features or functionality to a W... More developer will eventually benefit.

But the tool isn’t fully ready for all use cases yet. And that’s where you come in.

In this article, we’ll break down what @wordpress/build does, why it matters, and how it affects different types of WordPress users: from coreCore The foundational files and code of WordPress itself, ma... More contributors to block developers to agency builders.

What Is @wordpress/build?

@wordpress/build is a new build tool introduced by JuanMa Garrido and the WordPress coreCore The foundational files and code of WordPress itself, ma... More team. It’s designed to:

• Replace webpack + Babel with a significantly faster engine (currently esbuild).
• Auto-discover JavaScriptA programming language used to create interactive elements o... More packages, adminThe admin (administrator) is the highest user role with full... More routes, and (soon) blocks based on folder conventions, no manual entry points.
• Auto-generate PHP registration files (build.php, scripts.php, etc.) so you don’t need to manually register scripts or styles.
• Handle external dependencies via a namespace model, making cross-plugin interoperability seamless.

The tool is already powering Gutenberg’s 100+ packages. The next step is integrating it into @wordpress/scripts so every WordPress developer benefits.

How It Works (In Simple Terms)

Instead of configuring webpack entry points, you just follow folder conventions:

my-plugin/
├── packages/          # JavaScript packages (auto-built)
├── routes/            # Admin page routes (experimental)
└── blocks/            # Proposed: auto-discovered blocks

Inside each package, you add a package.json with simple flags like "wpScript": true. That’s it.

Run wp-build, and the tool:

1. Discovers all packages.
2. Bundles them (using esbuild, not webpack).
3. Generates PHP files to register everything with WordPress.
4. Handles dependencies automatically, no more manual wp_enqueue_script or .asset.php management.

Why This Matters

For Everyday Block Developers

You’ve been using @wordpress/create-block or @wordpress/scripts. Good news: your workflow likely won’t change. When @wordpress/build becomes the default engine, you’ll get:

• Faster builds (minutes → seconds).
• Less boilerplate (no manual PHP registration).
• Smarter dependency management (imports from other plugins just work).

But for now, stick with @wordpress/scripts unless you’re experimenting. The migration will happen automatically later.

For Plugin Developers with Multiple Scripts or Admin Pages

If your pluginSoftware that adds specific features or functionality to a W... More has several entry points (e.g., a settings pageStatic content (e.g., "About Us," "Contact") not part of chr... More, a block, and a frontend script), @wordpress/build is worth evaluating today. The convention-based approach eliminates repetitive webpack config and PHP enqueuing.

Example: Want a new adminThe admin (administrator) is the highest user role with full... More pageStatic content (e.g., "About Us," "Contact") not part of chr... More? Add a folder under routes/. Want a new block? Add a folder under blocks/ (once supported). The tool handles the rest.

For Agency and Product Builders

If you maintain multiple plugins or a large custom block library, the namespace model is a game-changer. You can declare external dependencies from other plugins (e.g., WooCommerce) and @wordpress/build will automatically ensure scripts load in the right order — no manual dependency arrays.

"wpPlugin": {
  "externalNamespaces": {
    "woo": { "global": "woo", "handlePrefix": "woocommerce" }
  }
}

For Gutenberg Contributors

You’re already using @wordpress/build when you run npm start in GutenbergGutenberg The block editor introduced in WordPress 5.0, usin... More. Understanding wpPlugin config and externals resolution helps you debug build issues and contribute more effectively.

For the WordPress Ecosystem

This shift represents a philosophical move: convention over configuration. WordPress is absorbing complexity into tooling so developers can focus on features, not build pipelines. That’s a win for the entire community.