@wordpress/build là gì? Tooling mới cho plugin WordPress

Bạn đã từng mở một plugin WordPress và thấy webpack config, Babel config, entry points, asset PHP và script registration nằm rải rác khắp nơi chưa? Nếu có, bạn sẽ hiểu vì sao cộng đồng WordPress đang thử một hướng build tooling mới: ít cấu hình hơn, nhiều convention hơn.

@wordpress/build là một package mới trong hệ sinh thái Gutenberg. Nó chưa phải thứ mọi plugin cần migrate ngay hôm nay, nhưng đủ quan trọng để developer WordPress nên hiểu từ bây giờ. Cùng xem nhé!

@wordpress/build là gì?

@wordpress/build là một build system mới cho plugin WordPress, được thiết kế để thay thế nhiều phần cấu hình webpack/Babel bằng convention và một pipeline build thống nhất. Theo WordPress Developer Blog, công cụ này xử lý scripts, script modules và styles trong một lần chạy, đồng thời tự tạo lớp PHP registration dựa trên package conventions [1].

Nếu nói đơn giản, @wordpress/build cố gắng trả lời câu hỏi: “Tại sao developer phải vừa biết bundler JavaScript, vừa viết asset metadata, vừa tự đăng ký script/style trong PHP cho cùng một plugin?” Thay vì mỗi dự án tự ghép các mảnh đó, tool mới dùng folder và package.json để suy luận phần còn lại.

README chính thức trong Gutenberg mô tả @wordpress/build là build tool cho plugin WordPress, hỗ trợ transpilation TypeScript/JSX, style compilation, bundling cho WordPress scripts/modules, PHP generation và watch mode [2]. Đây là hướng khá khác với cảm giác “copy một webpack config rồi sửa dần” mà nhiều dự án WordPress từng dùng.

@wordpress/build

Build system hướng convention cho plugin WordPress, dùng để build JavaScript, script modules, styles và sinh file PHP registration tương ứng.

Vì sao WordPress cần build tooling mới?

WordPress cần build tooling mới vì plugin hiện đại không còn chỉ là vài file PHP; chúng thường có React UI, block editor integration, script modules, SCSS và nhiều entry point. Càng nhiều mảnh, cấu hình thủ công càng dễ lệch.

@wordpress/scripts đã giúp chuẩn hóa rất nhiều thứ cho block development. Tài liệu Block Editor Handbook mô tả package này như một tập hợp reusable scripts có cấu hình khuyến nghị sẵn, giúp developer tránh tự bảo trì quá nhiều tool riêng [3]. Với nhiều dự án, đây vẫn là nền tảng tốt.

Vấn đề xuất hiện khi plugin có kiến trúc lớn hơn: nhiều package nội bộ, admin page riêng, module dùng chung, styles riêng cho editor/frontend và nhu cầu tối ưu dependency. Nếu mỗi entry point phải khai báo thủ công và mỗi asset phải đăng ký thủ công, chi phí bảo trì tăng rất nhanh.

@wordpress/build đi theo hướng khác: dùng convention để phát hiện folder, bundle code, externalize package đúng cách và sinh file đăng ký PHP. Mình thích hướng này ở điểm nó giảm “glue code” không tạo giá trị nghiệp vụ, nhưng vẫn cần thực tế: tool còn đang được định hình, nên chưa nên ép mọi dự án migrate.

@wordpress/build hoạt động theo convention nào?

@wordpress/build dựa vào folder và package metadata để tự phát hiện thứ cần build. Bài giới thiệu chính thức nêu hai convention đáng chú ý: thư mục packages cho JavaScript packages và thư mục routes cho admin page routes [1].

Trong mô hình này, mỗi entry point có thể là một package nhỏ có package.json riêng. Package có thể khai báo cách expose script hoặc script module, còn build tool lo phần bundling và registration. Với plugin lớn, cách chia nhỏ này giúp codebase rõ ownership hơn.

Một lợi ích lớn là auto-generated PHP registration. WordPress Developer Blog giải thích rằng chỉ cần require file build/build.php trong plugin chính, phần generated sẽ load scripts.php, modules.php và styles.php để đăng ký script, module và style mà package tạo ra [1]. README cũng liệt kê PHP Generation là một năng lực chính của tool [2].

Điều này đặc biệt quan trọng khi WordPress ngày càng hỗ trợ script modules. Code Reference cho WP_Script_Modules cho thấy core có lớp riêng để register, enqueue, dequeue và xử lý dependency cho script modules [5]. Build tool hiểu lớp này sẽ giúp developer ít viết boilerplate hơn.

@wordpress/build khác @wordpress/scripts ra sao?

@wordpress/scripts là tool public quen thuộc cho đa số dự án hiện nay, còn @wordpress/build là engine mới đang được định hình cho kiến trúc plugin phức tạp hơn. Vì vậy, câu hỏi đúng không phải “tool nào thắng”, mà là “dự án của bạn đang ở mức phức tạp nào”.

Bài chính thức cũng nói rõ phần lớn developer đang dùng @wordpress/scripts sẽ không cần đổi gì khi quá trình chuyển tiếp diễn ra [1]. Đây là câu quan trọng, vì nó giúp tránh tâm lý “tool mới là phải migrate ngay”.

Nếu bạn đang làm một block đơn giản bằng @wordpress/create-block, mình khuyên bạn tiếp tục dùng workflow hiện tại. Nếu bạn đang maintain plugin có nhiều màn hình admin và nhiều bundle, hãy thử @wordpress/build để xem nó có giảm được cấu hình lặp và PHP boilerplate không.

Khi nào nên thử @wordpress/build?

Bạn nên thử @wordpress/build khi plugin có nhiều script/module/style cần đăng ký, nhiều package nội bộ hoặc admin page routes đủ phức tạp để cấu hình hiện tại trở thành gánh nặng. Nếu plugin đơn giản và đang build ổn, chưa cần động vào production pipeline.

Nhóm nên thử sớm gồm Gutenberg contributors, developer làm plugin nhiều entry point, team muốn góp ý cho tương lai build tooling WordPress và dự án đang đau vì PHP registration thủ công. Bài chính thức cũng nhấn mạnh API còn đang malleable, tức feedback từ developer lúc này có giá trị [1].

Nhóm nên chờ gồm plugin một block, plugin ổn định với webpack hiện tại, theme chỉ cần build asset cơ bản hoặc team chưa có staging/test đủ tốt. Chờ không có nghĩa là tụt hậu; đôi khi đó là quyết định kỹ thuật đúng để bảo vệ khách hàng.

Để thử an toàn, hãy tạo một branch riêng, dựng một plugin mẫu có kiến trúc giống production, chạy build, kiểm tra generated PHP, kiểm tra dependencies trong asset files, rồi mở WordPress staging để xác nhận editor/frontend không lỗi. Bạn có thể kết hợp với bài GitHub Actions CI/CD cho website nếu muốn đưa bước build vào pipeline.

Ví dụ cấu trúc plugin tham khảo

Cấu trúc tốt cho @wordpress/build nên làm rõ ranh giới giữa package JavaScript, route admin và output build. Mục tiêu không phải làm folder phức tạp, mà là giúp tool và developer cùng hiểu plugin đang có những phần nào.

my-plugin/
  my-plugin.php
  package.json
  packages/
    editor-panel/
      package.json
      src/
        index.js
    shared-ui/
      package.json
      src/
        index.js
  routes/
    settings/
      package.json
      src/
        index.js
  build/
    build.php
    scripts.php
    modules.php
    styles.php

Trong plugin chính, ý tưởng là load file registration được sinh ra thay vì tự viết toàn bộ enqueue layer. Ví dụ dưới đây chỉ mang tính minh họa, không phải template bắt buộc cho mọi dự án.

<?php
/**
 * Plugin Name: My Plugin
 */

// Nạp lớp đăng ký script/module/style do build tool tạo ra.
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';

Điểm cần test kỹ là dependency resolution. Nếu một package import package khác trong cùng plugin, bạn muốn build output không nhân đôi code không cần thiết và WordPress biết load dependency đúng thứ tự. Với plugin thương mại, đây là nơi E2E test và review bundle size nên đi cùng nhau.

Bạn đang đọc bài viết thuộc chuyên mục Lập trình của VietnamTutor. Nếu bạn đang thiết kế lại workflow build cho plugin khách hàng, đừng chỉ đổi tool; hãy đổi cả cách test, release và rollback.

Nguồn tham khảo

1. WordPress Developer Blog: @wordpress/build, the next generation of WordPress plugin build tooling
2. GitHub WordPress/gutenberg: @wordpress/build README
3. WordPress Block Editor Handbook: @wordpress/scripts
4. npm: @wordpress/build package
5. WordPress Developer Resources: WP_Script_Modules
6. WordPress Theme Handbook: Build Process

@wordpress/build là một tín hiệu đáng chú ý: WordPress đang nghiêm túc hơn với developer experience cho plugin phức tạp. Nhưng tool mới không tự làm dự án tốt hơn. Điều đáng làm là thử có kiểm soát, đo xem nó giảm được bao nhiêu cấu hình lặp, rồi quyết định bằng dữ liệu của chính plugin bạn.