Herramientas modernas de WordPress: Vite, webpack y la cadena de construcción 2026

La forma en que construyo sitios WordPress ha cambiado fundamentalmente. En 2026, el rendimiento de tu cadena de construcción es tan importante como el rendimiento de tu sitio web. Si tu “npm run dev” tarda 30 segundos en arrancar, estás perdiendo horas de productividad cada semana. Para los desarrolladores profesionales de WordPress que trabajan en proyectos empresariales, está ineficiencia se multiplica en miles de dolares de productividad pérdida anualmente.

Aquí está la guía completa de herramientas profesionales de WordPress para 2026, cubriendo todo desde herramientas de construcción hasta pipelines de despliegue.

#Por qué Vite está reemplazando a Webpack en WordPress

Vite se ha convertido en el estándar de oro para el desarrollo moderno de WordPress. Mientras que Webpack nos sirvió bien durante una década, su enfoque de “empaquetar primero” es demasiado lento para proyectos Gutenberg modernos y con muchos datos que requieren retroalimentación instantánea durante el desarrollo.

#Tiempo de arranque y de recarga en Vite y Webpack

Enfoque de Webpack:

• Empaqueta todo el código base antes de iniciar el servidor de desarrollo
• Tiempo de arranque en frio: 15-45 segundos para proyectos grandes
• Recarga en caliente: 2-5 segundos por cambio
• Intensivo en memoria: A menudo requiere 4GB+ de RAM

Enfoque de Vite:

• Usa módulos ES nativos en el navegador durante el desarrollo
• Tiempo de arranque en frio: <1 segundo, independientemente del tamaño del proyecto
• Hot Module Replacement: <100ms para la mayoría de cambios
• Uso eficiente de memoria: Típicamente menos de 1GB de RAM

#Cuánto tiempo ahorra Vite al día

Considera un día típico para un desarrollador WordPress:

• 50 guardados de archivo durante el desarrollo
• Flujo de trabajo con Webpack: 50 x 5 segundos = 250 segundos (4+ minutos) perdidos en recargas
• Flujo de trabajo con Vite: 50 x 0.1 segundos = 5 segundos en total
• Tiempo ahorrado por día: 4 minutos. Por año: 16+ horas

#Configuración de Vite para WordPress

El desafío principal con Vite es integrarlo con el backend PHP de WordPress. Plugins pequeños como vite-plugin-wordpress (versión 1.0.4 en npm) se encargan de la conexión y, según su readme, hacen menos de lo que sugiere el nombre:

1. Escriben un fichero vite.config.php en el directorio de configuración del proyecto, con la información que PHP necesita para resolver las rutas de los ficheros generados por Vite
2. En modo desarrollo, escriben un fichero .dev con la URL del servidor de desarrollo de Vite, para que PHP sepa si debe cargar desde el servidor de desarrollo o desde el build
3. Opcionalmente vigilan ficheros y lanzan una recarga completa (la opción watch, basada en vite-plugin-live-reload)

Imprimir las etiquetas script y encolar los ficheros sigue siendo tarea de tu tema. Lo explica la sección sobre el manifiesto, más abajo.

// vite.config.js - Configuración moderna de WordPress
import { defineConfig } from 'vite';
import wordpress from 'vite-plugin-wordpress';

export default defineConfig({
  plugins: [
    wordpress({
      watch: true,
      devDir: process.cwd(),
      wordpressConfigDir: 'config'
    })
  ],
  build: {
    outDir: 'dist',
    manifest: true,
    rolldownOptions: {
      input: {
        main: './src/index.js',
        blocks: './src/blocks/index.js'
      }
    }
  }
});

#Cuando seguir usando Webpack

Webpack sigue siendo necesario para:

• Proyectos legacy que no pueden migrarse inmediatamente
• Requisitos de empaquetado complejos (división de código en múltiples puntos de entrada)
• Proyectos que requieren ecosistemas extensos de plugins
• Equipos con profunda experiencia en Webpack y sin tiempo para reentrenamiento

Sin embargo, para proyectos nuevos en 2026, Vite es casi siempre la mejor opción.

#Cómo compila @wordpress/scripts los bloques de WordPress con webpack

Antes de pasar un plugin de bloques a Vite, conviene saber qué hace ya el conjunto de herramientas oficial, porque es justo lo que va a sustituir. La referencia de @wordpress/scripts en developer.wordpress.org describe el paquete como una colección de scripts reutilizables para el desarrollo con WordPress, configurada en la sección scripts del package.json. Los comandos build y start funcionan sobre webpack. La versión 36.1.0 se publicó en npm el 7 de octubre de 2026, así que se trata de una configuración de webpack mantenida activamente y no de un resto heredado.

wp-scripts build genera un build de producción y wp-scripts start recompila de forma incremental mientras trabajas. Si no indicas puntos de entrada, el directorio de código (por defecto ./src) se recorre en busca de ficheros block.json, y los ficheros JavaScript indicados en sus campos de script se convierten en puntos de entrada. Si no hay ningún block.json, el punto de entrada de reserva es src/index.js (o .jsx, .ts, .tsx), con salida en build/index.js.

Las opciones que importan para los temas de este artículo:

El conjunto oficial ya tiene, por tanto, recarga en caliente para bloques, con dos condiciones fáciles de pasar por alto en una copia de staging con SCRIPT_DEBUG desactivado.

El mismo paquete cubre el resto de la cadena: lint-js (ESLint con @wordpress/eslint-plugin), lint-style (stylelint con @wordpress/stylelint-config), format, test-unit-js (ejecuta el Vitest instalado en el proyecto), test-e2e (Playwright), plugin-zip y packages-update. Para cambiar la configuración de webpack se crea un webpack.config.js en la raíz del proyecto, se carga la configuración por defecto con require y se amplía con el operador spread, sin dejar de ejecutar los comandos wp-scripts en lugar de llamar a webpack directamente.

#Qué contiene el fichero index.asset.php

Cada punto de entrada compilado con la configuración por defecto recibe su fichero .asset.php. Lo genera el Dependency Extraction Webpack Plugin, y devuelve la lista de dependencias y una versión calculada a partir del código fuente:

<?php return array( 'dependencies' => array( 'react' ), 'version' => 'dd4c2dc50d046ed9d4c063a7ca95702f' );

El PHP pasa ambos valores directamente a la llamada de encolado, de modo que nadie mantiene la lista de dependencias a mano:

$asset = include plugin_dir_path( __FILE__ ) . 'build/index.asset.php';
wp_enqueue_script( 'my-block', plugins_url( 'build/index.js', __FILE__ ), $asset['dependencies'], $asset['version'] );

Qué implica esto al migrar a Vite se explica en la sección sobre dependencias de WordPress, más abajo.

#Cómo cargar los ficheros de Vite en el PHP de WordPress con el manifiesto

La guía de integración con backend de Vite es la referencia para cualquier configuración renderizada en el servidor, WordPress incluido. Tiene tres partes.

Configuración. Define el punto de entrada y active build.manifest: true. Tras vite build, Vite escribe el fichero .vite/manifest.json en el directorio de salida.

Desarrollo. Mientras vite está en marcha, la plantilla PHP imprime dos scripts de módulo que apuntan al servidor de desarrollo: @vite/client y su fichero de entrada, por ejemplo http://localhost:5173/@vite/client y http://localhost:5173/main.js. En server.cors indica el origen que abres en el navegador, es decir, la URL local de WordPress. Para imágenes y fuentes referenciadas desde el CSS, redirige las peticiones de ficheros a Vite mediante un proxy o define server.origin, para que las URL generadas apunten al host correcto.

Producción. PHP lee el manifiesto, un mapa de nombres de chunk a chunks. Para el punto de entrada toma file (el script que se carga), imprime un enlace de hoja de estilos por cada elemento de css y recorre imports de forma recursiva para añadir su CSS y enlaces modulepreload opcionales. Salvo que el polyfill de module preload esté desactivado, el punto de entrada debe empezar con import 'vite/modulepreload-polyfill'.

Vite genera módulos ES, así que en el lado de WordPress encaja mejor wp_enqueue_script_module(), disponible desde WordPress 6.5.0, que el clásico wp_enqueue_script():

$manifest = json_decode( file_get_contents( get_theme_file_path( 'dist/.vite/manifest.json' ) ), true );
$entry    = $manifest['src/index.js'];
wp_enqueue_script_module( 'theme-main', get_theme_file_uri( 'dist/' . $entry['file'] ) );
foreach ( $entry['css'] ?? array() as $i => $css ) {
	wp_enqueue_style( 'theme-main-' . $i, get_theme_file_uri( 'dist/' . $css ) );
}

El fichero .dev que escribe vite-plugin-wordpress es lo primero que este PHP puede comprobar: si existe, imprime las dos etiquetas del servidor de desarrollo y, si no, lee el manifiesto.

#Cómo usar TypeScript en bloques de WordPress

En 2026, JavaScript sin tipado se considera un riesgo para proyectos empresariales. TypeScript se ha convertido en el estándar de la industria, y con buena razón.

#Por qué TypeScript importa para WordPress

Prevención de errores: TypeScript captura errores antes de que el código se ejecute. Considera este error común en bloques Gutenberg:

// Sin TypeScript - Error en tiempo de ejecución
attributes: {
  color: 'red' // El desarrollador pasa accidentalmente un string
}
// Mas adelante en el código:
setAttributes({ color: { r: 255, g: 0, b: 0 }}) // Espera objeto, obtiene string

// Con TypeScript - Error en tiempo de compilacion
interface ColorAttributes {
  color: string;
}
// TypeScript captura la incompatibilidad inmediatamente

Seguridad en desarrollo de bloques: Como los bloques Gutenberg dependen en gran medida de objetos attributes complejos, TypeScript asegura seguridad de tipos en:

• Atributos de bloques
• Controles del inspector
• Renderizado del lado del servidor
• Respuestas de API

#Configuración de TypeScript para WordPress

// tsconfig.json - Optimizado para WordPress
{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "lib": ["ES2020", "DOM"],
    "jsx": "react",
    "moduleResolution": "node",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "resolveJsonModule": true,
    "types": ["@wordpress/blocks"]
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

#Dónde se usa TypeScript en proyectos WordPress

Dónde aparece TypeScript de verdad en el trabajo con WordPress:

• código del editor de bloques, donde las formas de los datos están documentadas y son estables
• todo lo que toca la REST API, donde una errata en el nombre de un campo se descubre en ejecución
• paquetes compartidos dentro de una agencia, donde los tipos son el contrato entre equipos

#Cómo migrar un proyecto WordPress a TypeScript

Para proyectos existentes, la migración a TypeScript puede ser gradual:

1. Comienza con archivos nuevos (extensión .ts)
2. Convierte gradualmente archivos críticos (bloques, manejadores de API)
3. Usa comentarios // @ts-check para victorias rápidas en archivos existentes
4. Habilita el modo estricto incrementalmente

#HMR en el desarrollo de bloques Gutenberg

HMR es fluido y transformador para la experiencia del desarrollador.

#Tiempo por iteración con y sin HMR

Flujo de trabajo tradicional:

1. Editar CSS de un bloque Gutenberg
2. Guardar archivo
3. Esperar la construcción (5 segundos)
4. Recargar navegador
5. Navegar a la página (10 segundos)
6. Abrir el editor de bloques
7. Navegar 10 niveles profundo hasta la configuración en la que trabajas
8. Verificar el cambio
9. Repetir para la siguiente iteración

Tiempo total por iteración: 20-30 segundos

Flujo de trabajo moderno con HMR:

1. Editar CSS de un bloque Gutenberg
2. Guardar archivo
3. El cambio aparece instantáneamente en el navegador (<100ms)
4. Sin pérdida de navegación, sin cambio de contexto

Tiempo total por iteración: <1 segundo

#Qué actualiza HMR en los bloques Gutenberg

Las herramientas de construcción modernas manejan automáticamente HMR para:

• Cambios de CSS (actualizaciones visuales instantáneas)
• Cambios de JavaScript (preservando el estado del componente)
• Actualizaciones de componentes React (manteniendo el estado del editor)
• Cambios de assets (imágenes, fuentes)

#Ventajas de HMR en el desarrollo diario de bloques

En el trabajo diario, HMR se nota en tres puntos:

• una iteración termina con un módulo reemplazado, no con una recarga completa
• te quedas en el editor en lugar de saltar al navegador y volver
• el fallo aparece mientras el cambio sigue fresco, no después de recompilar

#CSS por bloque y theme.json en temas FSE

Los temas de Full Site Editing (FSE) requieren un enfoque fundamentalmente diferente para estilos y gestión de assets.

#Cómo generar theme.json desde tokens de diseño

En 2026, generamos theme.json dinámicamente desde tokens de diseño:

// build-theme-json.js
import designTokens from './figma-tokens.json' with { type: 'json' };

const themeJson = {
  settings: {
    color: {
      palette: designTokens.colors.map(color => ({
        slug: color.name,
        color: color.value,
        name: color.label
      }))
    },
    typography: {
      fontFamilies: designTokens.fonts.map(font => ({
        slug: font.name,
        fontFamily: font.value
      }))
    }
  }
};

// Auto-generar theme.json desde tokens de Figma

Este enfoque asegura:

• Consistencia del sistema de diseño en todo el tema
• Fuente única de verdad, de Figma a WordPress
• Actualizaciones automáticas cuando cambian los tokens de diseño
• Reducción de errores de configuración manual

#Cómo cargar CSS solo para los bloques de la página

En 2026, no cargamos un solo style.css. Las cadenas de construcción modernas automáticamente:

1. Analizan el uso de bloques en cada página
2. Dividen el CSS por tipo de bloque
3. Cargan solo los estilos necesarios para los bloques presentes en la página
4. Insertan CSS crítico para contenido sobre el pliegue

Esto resulta en:

• la hoja de estilos enviada contiene solo las clases que las plantillas usan realmente
• First Contentful Paint (FCP) más rápido
• Mejores puntuaciones de Core Web Vitals
• Mejor rendimiento móvil

#Cómo configurar la división de CSS en Vite

// Estrategia moderna de división de CSS (Vite 8)
export default {
  build: {
    cssCodeSplit: true,
    rolldownOptions: {
      output: {
        assetFileNames: 'assets/[name].[hash][extname]',
        chunkFileNames: 'assets/[name].[hash].js',
        codeSplitting: {
          groups: [
            { name: 'core-blocks', test: /src\/blocks\/core/ },
            { name: 'custom-blocks', test: /src\/blocks\/custom/ },
            { name: 'editor-styles', test: /src\/editor/ }
          ]
        }
      }
    }
  }
}

#Vite vs Webpack vs Parcel vs esbuild en 2026

#Qué herramienta de build elegir para WordPress

Elige Vite si:

• Comienzas un nuevo proyecto WordPress
• Usas JavaScript moderno (módulos ES)
• Necesitas experiencia de desarrollo rápida
• Trabajas con temas FSE o bloques Gutenberg
• El equipo valora la experiencia del desarrollador

Elige Webpack si:

• Mantienes proyectos WordPress legacy
• Requieres un ecosistema extenso de plugins
• Tienes requisitos complejos de división de código
• El equipo tiene profunda experiencia en Webpack
• El riesgo de migración es demasiado alto

Elige Parcel si:

• Construyes plugins WordPress simples
• Quieres configuración cero
• Prefieres convención sobre configuración
• Proyectos pequeños a mediaños

#npm vs yarn vs pnpm para temas WordPress

En 2026, la elección del gestor de paquetes impacta significativamente el rendimiento de construcción.

#Tiempo de instalación y espacio en disco en npm, yarn y pnpm

Para un tema WordPress típico con 150 dependencias:

#Por qué pnpm instala más rápido y ocupa menos disco

pnpm usa un almacén direcciónable por contenido:

• Los paquetes se almacenan una sola vez globalmente
• Los proyectos enlazan al almacén global (enlaces duros)
• el uso de disco crece con el número de versiones distintas, no con el número de proyectos
• Instalaciones más rápidas (sin descargas duplicadas)

La documentación de pnpm explica el mecanismo: cuando se actualiza una dependencia, solo los ficheros que cambian entran en el almacén. Una versión nueva de un paquete de 100 ficheros en la que cambia un fichero añade, por tanto, un fichero. Los proyectos reciben enlaces duros al almacén en lugar de copias. La misma página no da cifras de benchmark, así que lee los tiempos de instalación de la tabla anterior como una ilustración para un tema, no como una medición reproducible.

# Configuración moderna de proyecto WordPress
pnpm create vite@latest mi-tema-wordpress
cd mi-tema-wordpress
pnpm install

#Últimas versiones de Vite, webpack y @wordpress/scripts en 2026

Las versiones citadas en artículos sobre herramientas de build envejecen rápido. Estas son las versiones actuales según el registro de npm (campo time de cada paquete) a 15 de octubre de 2026:

Dos de estas versiones cambian el código de este artículo. Vite 8 usa Rolldown y Oxc en lugar de esbuild y Rollup: build.rollupOptions queda obsoleto y pasa a llamarse build.rolldownOptions, la forma de objeto de output.manualChunks ya no se admite y la forma de función queda obsoleta en favor de la opción codeSplitting de Rolldown. Los ejemplos de Vite de arriba ya usan los nombres nuevos. Turbo 2.0 cambió el nombre de la clave pipeline de turbo.json a tasks. La referencia de codemods de Turborepo lo recoge como rename-pipeline, que se aplica junto con el resto de cambios de la 2.0 mediante npx @turbo/codemod migrate.

webpack 5, en cambio, lleva seis años como versión principal actual. @wordpress/scripts avanza rápido: las versiones principales 33 a 36 salieron entre julio y septiembre de 2026, así que fija la versión en package.json y lee el changelog antes de ejecutar packages-update.

#Monorepo WordPress para agencias con Turbo

Para agencias que gestionan 50+ sitios WordPress, 2026 es el año del Monorepo.

#Beneficios de la arquitectura monorepo

1. Biblioteca de componentes compartidos: Una biblioteca “Core Component” usada en todos los sitios de clientes
2. Herramientas consistentes: Mismás herramientas de construcción, linting y testing en todos los proyectos
3. Actualizaciones atómicas: Actualiza un componente compartido una vez, despliega a todos los sitios
4. Construcciones paralelas: Turbo o Nx pueden construir/testear múltiples proyectos simultáneamente

#Cómo configurar turbo.json para WordPress

// turbo.json
{
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**"]
    },
    "test": {
      "dependsOn": ["build"]
    },
    "lint": {}
  }
}

#Qué cambia un monorepo en el día a día de una agencia

Qué cambia en el trabajo diario:

• una instalación y un lockfile en lugar de uno por proyecto
• el código compartido pasa a un paquete, así una corrección entra una vez y no en cada repositorio
• alguien que se incorpora ejecuta los mismos comandos en todos los proyectos
• una subida de dependencias se revisa una vez, en un solo pull request

#Herramientas de build de WordPress en CI/CD

Las herramientas de construcción modernas se integran perfectamente con servicios profesionales de desarrollo WordPress:

• Pipelines CI/CD: Construcciones automatizadas en cada commit
• Calidad de código: ESLint, Prettier, TypeScript integrados
• Testing: Jest, Vitest para pruebas unitarias
• Despliegue: Despliegue automatizado a staging/producción

Para tiendas WooCommerce, las herramientas modernas permiten:

• Desarrollo más rápido de flujos de checkout personalizados
• Vista previa en tiempo real de integraciones de pago
• Iteración rápida en componentes de visualización de productos

#Cómo analizar el tamaño del bundle y el tiempo de build

Las herramientas de construcción modernas proporcionan información de rendimiento integrada:

• Análisis de bundles: Identificar dependencias grandes
• Seguimiento de tiempo de construcción: Monitorear el rendimiento de construcción a lo largo del tiempo
• Optimización de assets: Minificacion automática, tree-shaking
• Generación de source maps: Mejor depuración en producción

Estas herramientas ayudan a mantener un rendimiento rápido de WordPress durante todo el ciclo de vida del desarrollo.

#Dependencias de WordPress al migrar a Vite

Hay un punto en el que casi todas las migraciones se atascan, y no aparece en los tutoriales: las dependencias de WordPress. @wordpress/scripts usa un plugin de extracción que detecta cada importación de @wordpress/*, la deja fuera del bundle, la convierte en el global correspondiente (wp.blocks, wp.element, wp.i18n) y genera un fichero .asset.php con la lista de handles y un hash de versión. Ese fichero es lo que después pasas a wp_enqueue_script() como dependencias.

Vite no hace nada de eso por defecto. Si migras sin resolverlo, el bundle incluye una copia propia de React y del paquete de bloques, el editor carga dos instancias distintas y el síntoma típico es un bloque que se registra pero no responde a los cambios de atributos, sin ningún error en consola.

Las dos salidas honestas son: declarar los paquetes como external en build.rolldownOptions (la configuración de Rollup en versiones anteriores a Vite 8) y mapearlos a los globales a mano, o usar un plugin de la comunidad que replique la extracción. En ambos casos, la comprobación es la misma: abre el HTML generado y confirma que el handle wp-element aparece como dependencia y no dentro de tu propio fichero JavaScript.

#Cómo migrar un tema WordPress de Webpack a Vite

En un proyecto que ya está en producción, migrar todo de golpe hace difícil saber qué cambio rompió qué. Este orden deja el tema funcionando después de cada paso:

1. Decide si migras. Si el tema depende de un ecosistema amplio de plugins de Webpack o de una división de código compleja en varios puntos de entrada, quedarse puede ser la opción razonable.
2. Resuelve primero las dependencias de WordPress. Declara los paquetes @wordpress/* como external o usa un plugin que replique la extracción, y comprueba en el HTML generado que wp-element aparece como dependencia.
3. Conecta Vite con PHP mediante vite-plugin-wordpress y confirma que el HMR funciona en un bloque sencillo antes de pasar a los complejos.
4. Introduce TypeScript por partes: archivos nuevos en .ts, // @ts-check en los existentes y el modo estricto al final.
5. Si quieres pasar a pnpm, hazlo en un paso aparte, para que un fallo de instalación no se confunda con uno de construcción.

Con este orden, cuando un bloque deja de responder a los cambios de atributos, sabes en qué paso buscar.

#Conclusión

Las herramientas que usas definen la calidad del producto que entregas. Al adoptar Vite, TypeScript y cadenas de construcción modernas, te aseguras de que tu proceso de desarrollo sea tan rápido y fiable como los sitios web que construyes.

Para desarrolladores profesionales de WordPress y agencias, las herramientas modernas no son opcionales, son esenciales para mantenerse competitivos. Las ganancias de productividad de construcciones más rápidas, mejor seguridad de tipos y HMR fluido se multiplican en un valor comercial significativo.

Todavía estás esperando a que Webpack termine? Es hora de actualizar tus herramientas.

Deseas modernizar tu flujo de trabajo de desarrollo WordPress? Me especializo en desarrollo WordPress personalizado usando los últimos estándares de herramientas de 2026. Puedo ayudarte a migrar tus proyectos existentes a Vite, configurar TypeScript o construir nuevos proyectos con arquitectura moderna desde el inicio. Contáctame para comenzar.