@wordpress/build es la nueva herramienta de construcción para plugins de WordPress que reemplaza webpack y Babel con esbuild, auto-genera el registro PHP de scripts y funciona sin configuración. Según el anuncio oficial de WordPress Developer Blog publicado en abril de 2026, ya se usa internamente en Gutenberg y reduce los tiempos de compilación de minutos a segundos.
En 30 segundos
- @wordpress/build reemplaza webpack + Babel en el stack de plugins WordPress, usando esbuild (escrito en Go) como motor de compilación.
- Los tiempos de build pasaron de ~7 segundos a ~300ms en proyectos medianos, según las métricas del equipo de Gutenberg.
- Genera automáticamente el archivo PHP con el registro de scripts, lo que antes era un paso manual o dependía de herramientas externas.
- Funciona con cero configuración para la mayoría de casos: detecta carpetas
packages/yroutes/automáticamente. - @wordpress/scripts no desaparece todavía, pero webpack y Babel serán deprecados de esa herramienta en favor de @wordpress/build.
WordPress es un sistema de gestión de contenidos de código abierto para crear, publicar y administrar sitios web, desarrollado originalmente por Matt Mullenweg y mantenido por The WordPress Foundation.
Qué es @wordpress/build: la nueva herramienta de construcción para plugins
@wordpress/build es un paquete npm oficial del proyecto WordPress que compila JavaScript moderno para plugins y temas usando esbuild como motor. La diferencia central con el sistema anterior: no necesitás un archivo de configuración para empezar, detecta la estructura del proyecto automáticamente y el registro PHP de los scripts lo genera solo.
Si alguna vez configuraste un plugin con @wordpress/scripts, sabés que el flujo termina siendo: webpack compile, después vos escribís (o copiás de algún tutorial) el wp_enqueue_script() con el handle correcto, el path al .js compilado y las dependencias. Con @wordpress/build ese último paso desaparece. El archivo PHP con la llamada a wp_register_script() se crea solo al compilar.
Arrancó como la herramienta interna del equipo de Gutenberg. Lo que ahora publicaron como paquete público es exactamente lo que ya usaban para construir el editor de bloques.
Por qué WordPress dejó de usar Webpack y Babel
El problema con @wordpress/scripts no era webpack en sí, sino la capa de abstracción que se había acumulado encima. La arquitectura original de integración webpack + paquetes WordPress funcionaba, pero con el tiempo se fue volviendo un laberinto: configuraciones custom que rompían el preset de webpack, dependencias de Babel que no seguían el ritmo de los cambios de ECMAScript, y un sistema de entrypoints que requería que vos entendieras cómo webpack resuelve chunks para no terminar con bundles duplicados.
Cualquiera que haya tenido un plugin con bloques y páginas de administración conviviendo en el mismo proyecto se topó con esto: querés dos bundles separados, configurás dos entrypoints, webpack los procesa bien, pero las dependencias compartidas se duplican o se externalizan de formas raras dependiendo de la versión de @wordpress/scripts que tengas instalada.
¿Y Babel? Babel resolvía transpilación cuando los browsers no soportaban ES modules ni async/await. Hoy eso no es el problema que era en 2018. Seguir cargando todo el pipeline de Babel para compilar un plugin que va a correr en Chrome moderno y Safari reciente es, honestamente, más inercia que necesidad.
Ventajas clave de @wordpress/build frente a Webpack
La velocidad es la más obvia. esbuild reporta builds entre 10x y 100x más rápidos que herramientas equivalentes, y los números del equipo de Gutenberg lo confirman en la práctica: lo que antes tardaba entre 5 y 7 segundos en un build completo ahora tarda alrededor de 300ms. Para watch mode (el que usás mientras desarrollás), la diferencia es brutal.
Después está la auto-generación de PHP. Ponele que tenés un plugin con tres scripts: uno para el bloque, uno para la página de configuración en admin y uno para el frontend. Con webpack, vos manejás los tres registros a mano, o usás el archivo *.asset.php que genera @wordpress/dependency-extraction-webpack-plugin y construís el wp_enqueue encima. @wordpress/build genera directamente el PHP listo para usar. Menos código manual, menos errores de path, menos «por qué no carga el script en producción si en local andaba». Tema relacionado: desarrollo moderno de plugins WordPress.
El tercer punto es la convención sobre configuración. No hay webpack.config.js que mantener. Si tu proyecto sigue la estructura esperada (carpetas packages/ o routes/), @wordpress/build las detecta y compila todo sin que vos hagas nada. Para plugins chicos o medianos, esto significa que podés arrancar en cinco minutos sin tener que leer documentación de webpack.
Cómo funciona @wordpress/build internamente
El motor es esbuild, escrito en Go, lo que explica gran parte de la diferencia de velocidad. Go compila a binario nativo y esbuild evita deliberadamente el modelo de plugins de webpack (que permite mucha personalización pero introduce overhead). El tradeoff es que tenés menos flexibilidad para transformaciones raras, pero para el 95% de los plugins WordPress eso no importa.
La detección automática de carpetas funciona así: @wordpress/build busca entrypoints en packages/*/src/index.js (o .ts) y en routes/*/index.js. Cada uno se compila en un bundle separado. Si tu estructura no coincide exactamente, podés pasarle entrypoints custom por CLI, pero perdés parte de la magia del cero-configuración.
El watch mode hace incremental builds. Solo recompila los archivos que cambiaron, no el proyecto completo. En proyectos grandes (como el propio Gutenberg), esto es lo que hace que el tiempo de respuesta al guardar un archivo sea casi imperceptible. (En webpack con hot reload también tenés esto, pero la infraestructura que hay que configurar para llegar ahí es bastante más pesada.)
Un detalle que no queda tan claro en la documentación inicial: esbuild no transpila TypeScript con verificación de tipos. Lo compila y lo ignora. Si necesitás type checking como parte del build, tenés que correr tsc por separado o integrarlo en un paso pre-build. Esto es una decisión de diseño de esbuild, no un bug, pero habría que tenerlo presente antes de migrar si TypeScript es central en tu flujo.
Comparativa: @wordpress/build vs @wordpress/scripts vs Webpack puro
| Característica | @wordpress/build | @wordpress/scripts | Webpack puro |
|---|---|---|---|
| Velocidad de build | ~300ms (proyectos medianos) | ~5-7 segundos | Variable, configurable |
| Configuración requerida | Cero para casos estándar | Preset + config opcional | webpack.config.js completo |
| Auto-generación PHP | Sí, incluida | No (genera .asset.php parcial) | No |
| Compatibilidad con bloques | Parcial (workarounds para bloques) | Completa | Manual |
| TypeScript type-checking | No (compila sin verificar) | Sí (con configuración) | Sí (con ts-loader o babel) |
| Flexibilidad de configuración | Baja | Media | Alta |
| Motor de compilación | esbuild (Go) | webpack + Babel (Node.js) | webpack (Node.js) |
| Watch mode incremental | Sí, nativo | Sí, via webpack | Sí, via webpack |
Estado actual: qué ya funciona y qué todavía tiene limitaciones
@wordpress/build funciona bien para plugins con múltiples scripts JavaScript, módulos ES, y páginas de administración. También maneja módulos de WordPress (los paquetes @wordpress/*) como dependencias externas correctamente, lo que evita el problema clásico de bundlear wp-element o wp-i18n adentro del plugin. Ya lo cubrimos antes en plugins de formularios seguros.
El gap más importante ahora mismo: los plugins con bloques Gutenberg todavía necesitan workarounds. El registro de bloques depende de metadatos en block.json y de un flujo de build específico que @wordpress/build no maneja de forma nativa todavía. El equipo de WordPress lo reconoce explícitamente y la documentación menciona que la API «aún es maleable», lo que es un eufemismo honesto para decir que van a seguir cambiando cosas.
Si tu plugin tiene bloques como funcionalidad central, todavía conviene quedarse en @wordpress/scripts por ahora. Si tenés scripts para admin, assets del frontend, o módulos sin bloques, @wordpress/build ya es una opción sólida.
Cómo empezar: primeros pasos con @wordpress/build
La instalación es estándar:
npm install --save-dev @wordpress/buildEn tu package.json, agregás los scripts:
"scripts": {
"build": "wp-build",
"start": "wp-build --watch"
}Si tu código está en packages/mi-modulo/src/index.js, al correr npm run build va a generar el bundle en packages/mi-modulo/build/index.js y el archivo PHP de registro al lado.
Para migrar desde webpack existente, el proceso no es automático. Tenés que reorganizar los entrypoints para que coincidan con la estructura esperada, revisar si usás loaders de webpack que no tienen equivalente en esbuild (CSS Modules con cierta configuración, por ejemplo), y verificar que las dependencias de WordPress estén correctamente declaradas en package.json para que esbuild las trate como externas.
Lo más sano si ya tenés un plugin productivo: hacé la migración en una rama separada, compará los bundles generados (tamaño, contenido) y corré los tests antes de switchear. No es una migración de media hora en un plugin con historia.
Futuro de @wordpress/scripts y la migración planificada
El roadmap es claro: webpack y Babel van a ser deprecados dentro de @wordpress/scripts, y @wordpress/build se va a convertir en el motor de esa herramienta. Cuando eso pase, los desarrolladores que usan @wordpress/scripts van a obtener las mejoras de velocidad sin cambiar nada en su workflow. El comando wp-scripts build va a funcionar igual, pero por abajo va a usar esbuild. Lo explicamos a fondo en automatizar procesos de tu WordPress.
Ese es el escenario ideal para la mayoría de los desarrolladores de plugins: no hacer nada y que la mejora llegue sola. El equipo de WordPress está siendo deliberado en no forzar una migración inmediata, probablemente porque tienen presente lo que pasó con otras transiciones de herramientas en el ecosistema donde la documentación llegó después que la herramienta.
Para los equipos que quieran adoptarlo ahora, el beneficio principal no es solo velocidad: es menos dependencias que mantener. Sacar webpack.config.js del proyecto significa un vector menos de configuración que puede romperse con actualizaciones de Node o de los propios paquetes de WordPress.
Errores comunes al arrancar con @wordpress/build
Asumir que reemplaza @wordpress/scripts completamente. No lo hace, por lo menos no todavía. @wordpress/scripts sigue siendo la herramienta recomendada para plugins con bloques. @wordpress/build es para el resto, o para cuando @wordpress/scripts complete la migración interna.
Esto se conecta con @WordPress: R to @WordPress: @wordpress/build is a new build, donde profundizamos en el tema.
Esperar type-checking de TypeScript en el build. esbuild compila TypeScript pero ignora los errores de tipos. Si venías de un setup donde el build fallaba con errores de TypeScript, ese comportamiento desaparece. Tenés que agregar un paso separado de tsc --noEmit en tu pipeline CI si querés mantener esa seguridad.
Olvidar que la API todavía cambia. El equipo lo dice explícitamente: la API de @wordpress/build «es maleable». Antes de buildear algo crítico en producción con esta herramienta, fijate la versión exacta que instalás y no pongas ^ en el semver de ese paquete hasta que la herramienta tenga una versión estable oficial. Una actualización menor podría cambiar la estructura de salida o los paths de los archivos PHP generados.
Preguntas Frecuentes
¿Qué es @wordpress/build y para qué sirve?
@wordpress/build es un paquete npm oficial del proyecto WordPress que compila JavaScript para plugins usando esbuild como motor. Reemplaza webpack y Babel en el stack de build, funciona sin configuración para proyectos estándar y genera automáticamente el archivo PHP con el registro de scripts. Se usa internamente en Gutenberg desde 2026. Complementá con crear plugins especializados para WordPress.
¿Cuál es la diferencia entre webpack y esbuild para plugins WordPress?
webpack es un bundler escrito en Node.js con un sistema de plugins muy extensible, pero más lento. esbuild está escrito en Go, compila a binario nativo y prioriza velocidad sobre flexibilidad. Para plugins WordPress estándar, esbuild hace lo mismo que webpack pero entre 10x y 100x más rápido. El costo es que transformaciones muy custom (ciertas configuraciones de CSS Modules, loaders específicos) no tienen equivalente directo en esbuild.
¿Cuánto más rápida es la compilación con @wordpress/build?
El equipo de Gutenberg reporta tiempos de ~300ms con @wordpress/build versus ~5-7 segundos con webpack en proyectos de tamaño medio. En proyectos más grandes la diferencia es mayor porque esbuild hace builds incrementales nativamente. Los benchmarks son del propio equipo de WordPress, así que tomalo con pinzas para proyectos con estructura muy distinta a la de Gutenberg.
¿Necesito migrar mis plugins de webpack a @wordpress/build ahora?
Depende. Si tu plugin no tiene bloques Gutenberg, podés evaluar la migración ahora: los beneficios de velocidad son reales. Si tu plugin tiene bloques como funcionalidad central, conviene esperar a que @wordpress/build tenga soporte nativo para el flujo de block.json. En cualquier caso, el equipo de WordPress planea integrar @wordpress/build dentro de @wordpress/scripts, lo que traería las mejoras sin requerir migración manual.
¿Cómo empiezo a usar @wordpress/build en un plugin nuevo?
Instalás el paquete con npm install --save-dev @wordpress/build, organizás tu código en packages/tu-modulo/src/index.js y agregás "build": "wp-build" en los scripts de package.json. Al correr el build, genera el JavaScript compilado y el PHP de registro automáticamente. Para plugins con estructura no estándar o con bloques, revisá la documentación oficial antes de comprometerte con la migración.
Conclusión
@wordpress/build marca el fin del webpack obligatorio en el ecosistema de plugins WordPress. La velocidad de esbuild es real, la auto-generación de PHP resuelve un punto de fricción concreto, y el camino hacia integración en @wordpress/scripts ya está trazado.
El timing es el usual en herramientas nuevas: funciona bien para casos estándar, tiene gaps para los más complejos (bloques, TypeScript estricto), y la API todavía puede cambiar. Si arrancás un plugin nuevo hoy sin bloques, tiene sentido probarlo. Si tenés algo en producción con bloques como core, todavía no es el momento.
Lo que sí quedó claro es que webpack en WordPress tiene fecha de vencimiento. Cuándo exactamente depende de cuánto tarde el equipo de Gutenberg en terminar la migración interna de @wordpress/scripts. Pero la dirección no tiene vuelta atrás.
Fuentes
- WordPress Developer Blog – @wordpress/build: The Next Generation of WordPress Plugin Build Tooling (anuncio oficial)
- esbuild – Documentación oficial del motor de compilación
- WordPress Developer Blog – Cómo interactúan webpack y los paquetes de WordPress
- Deluxe Blog Tips – Análisis de esbuild para proyectos WordPress