@wordpress/build: The Next-Gen Plugin Build Tool Explained

WordPress plugin tooling is about to get dramatically faster

In April 2026, the WordPress developer blog announced @wordpress/build, a next-generation build tool intended to replace @wordpress/scripts as the official way to bundle WordPress plugins and blocks. If you maintain a WordPress plugin that ships blocks, admin UI, or any modern JavaScript, this affects you. The announcement is on developer.wordpress.org, and plugin authors should start planning the migration now, not after the first stable release drops.

This is the practical explainer: what changes, what stays compatible with existing code, why the WordPress project decided to make the change now, and how to migrate your plugin when the new tool is ready.

What @wordpress/scripts has been doing for us since 2019

For the last five-plus years, @wordpress/scripts has been the official build tool for WordPress plugins. It bundles webpack, babel-loader, css-loader, postcss, and a set of WordPress-specific defaults into a single npm run build command. Plugin authors drop it into package.json, run wp-scripts build, and get a clean build/ directory ready to register with register_block_type.

It was genuinely good when it landed. It replaced the previous situation where every plugin author rolled their own webpack configuration, and those rolled configurations were usually broken in at least one way. It is still what nearly every block plugin uses today in early 2026, and it will keep working for years. The retirement is gradual, not abrupt.

Why the replacement is happening now

Three structural issues have compounded over time and triggered the rewrite:

1. Webpack is showing its age. Native bundling in esbuild, Vite, Rolldown, and Bun is faster by an order of magnitude. Large plugin builds that take 8 to 15 seconds on webpack complete in under 2 seconds on esbuild-class tooling. On a 20-block plugin, that is the difference between tolerable and annoying.
2. Configuration escape hatches are awkward. When you need to extend @wordpress/scripts‘ webpack config for anything beyond the defaults, you override via a webpack.config.js that imports and merges the default. The pattern is brittle. One bad merge and your build silently produces wrong output.
3. The dev experience has not modernized. Hot module replacement in the block editor is partial at best. The asset manifest shape forces specific PHP patterns. Import-map-style module splitting is not practical without hand-configuring webpack.

The core team has been signaling a rewrite for about 18 months in various dev chat summaries. The public unveiling of @wordpress/build in April 2026 is the end of that signaling phase and the start of the transition phase.

What actually changes in @wordpress/build

From the public announcement and early Release Candidate code I have looked at:

• Bundler swap to Rolldown and esbuild. Builds are dramatically faster on real plugins. Benchmark numbers in the announcement show 8x improvements on medium-size plugin builds, and I measured similar on a 12-block client plugin (12 seconds down to 1.8).
• Configuration via wp-build.config.ts, TypeScript native, with types shipped in the package. No more guessing what options the config file accepts.
• First-class TypeScript support. Not a plugin, part of the default. You write .ts files in your source directory, the tool compiles them, done. No separate tsconfig juggling.
• Improved hot module replacement in the block editor. Changes to block edit components reflect without a full editor reload. The previous HMR experience was unreliable enough that most developers just refreshed.
• Cleaner asset manifest. The output .asset.php format is similar to the old one but with better source-map metadata and more accurate dependency resolution. Existing PHP code that reads the manifest should keep working without changes.
• Multi-entry point support by default. One config can build multiple blocks, an admin app, and a frontend view script without extra plumbing. The old tool technically supported this but the ergonomics were bad.
• Native ESM for dev. Browsers consume modules directly during development. Bundling only happens for production builds. This is why the dev server is so much faster.

What stays the same (good news for migration)

Good news for anyone who does not want a large migration project:

• The output directory shape. build/ still contains the compiled JS, CSS, and block.json copies. Existing register_block_type( __DIR__ . '/build/my-block' ) code continues to work without changes.
• The block.json format. No changes to block registration metadata.
• The enqueueing pattern. wp_enqueue_script with the generated .asset.php dependencies works identically.
• Your existing plugin source. Most edit.js, save.js, view.js, and SCSS files work without changes. If you were following the @wordpress/scripts conventions, the new tool reads your files the same way.

For plugins that use @wordpress/scripts in the most common way (register blocks via block.json, write standard edit and save components, no custom webpack overrides), migration will be close to zero code changes.

What a real migration looks like

For a typical block plugin using @wordpress/scripts, the migration goes like this:

Step 1. Install @wordpress/build alongside @wordpress/scripts:

Step 2. Update package.json scripts to add the new commands while keeping the legacy ones around during the transition:

Step 3. Create a wp-build.config.ts with the minimal config:

The entries pattern matches the src/blocks/ structure used by the create-block scaffolding, so if you scaffolded your plugin with the official tool, the config line above is all you need.

Step 4. Run npm run build. Verify that build/ contains the expected output and the plugin still works when loaded in WordPress. Compare against the output of npm run build:legacy (the old tool) to make sure nothing subtle changed.

Step 5. If you had a custom webpack.config.js, migrate the overrides to the new config API. The migration guide in the developer blog post covers the common patterns (custom loaders, path aliases, externalization of specific packages).

Plugins that will need real migration work

A minority of plugins use @wordpress/scripts in non-default ways, and these will need hands-on migration effort:

• Custom webpack loaders. Often for SVG-as-component, GraphQL query imports, or specific transpile requirements. These need to be reimplemented using the new plugin API, which is smaller and more explicit than webpack’s loader ecosystem.
• Non-block JavaScript builds. Plugins that use wp-scripts to build vanilla JS bundles for frontend use. The @wordpress/build config handles this, but the entry point configuration differs from the old tool.
• Monorepo setups. Agencies with shared component libraries that publish to a private npm registry and consume across plugins. The caching and resolution behavior is different on the new tool, and npm link behavior is stricter.
• Legacy JavaScript. Plugins still on ES5 or using Babel plugins that target older browsers. The new toolchain assumes modern browsers by default, and you can configure otherwise but it is explicit.

If any of these apply to your plugin, plan the migration for a specific development cycle rather than squeezing it in between features.

Timeline: when does this become the default?

Based on the announcement and the WordPress core team’s usual release cadence:

• April to May 2026: Public Release Candidate, active plugin-author testing and bug reports.
• Summer 2026: First stable release.
• Late 2026 to early 2027: @wordpress/scripts continues to be supported but marked as “legacy” in the documentation.
• 2027 and beyond: New plugins are expected to use @wordpress/build as the default. @wordpress/scripts moves to maintenance-only mode.

This is a reasonable timeline. Plugin authors have time. Enterprise agencies with dozens of plugin codebases have time to plan. Nobody is forced to migrate immediately, and the old tool will keep working for years.

Why this matters for the WordPress ecosystem

The WordPress developer experience for block plugins has lagged behind the modern frontend ecosystem. @wordpress/scripts was a leap forward in 2019, but by 2026, it is genuinely behind what developers expect from their tooling. Modern frontend teams joining WordPress projects often describe the tooling as dated, and the dated tooling is one of the reasons these teams sometimes decide to go headless instead. See my scaling freelance business guide for more context on how tooling quality affects agency hiring.

@wordpress/build closes most of that gap. Fast builds, native TypeScript, working hot module replacement. These are table stakes in 2026, and WordPress has been behind. The announcement is overdue and welcome, and the ecosystem momentum will move to the new tool faster than most people expect.

What to do this week

If you maintain a plugin:

1. Read the developer.wordpress.org announcement post carefully. It has migration-specific details that are easy to miss.
2. Try the RC on a development copy of one plugin, not production. Feel out the workflow differences before you commit.
3. File bugs early if you find them. The team is responsive during RC, and bugs filed in April are more likely to get fixed in the stable release than bugs filed in June.
4. Plan a migration cycle for your plugin portfolio, probably for late 2026 or early 2027. Budget a day per plugin, less if your plugins follow standard conventions.

For more on the broader WordPress 2026 tooling landscape including WordPress 7.0 and AI agents, see my March 2026 roundup. The tooling changes and the 7.0 release are connected, and planning for both together is cheaper than planning for them separately.