Trao đổi về dự án
Symfony

Symfony Reprise 1.0: di chuyển từ Webpack Encore sang Vite hoặc Rsbuild

Symfony Reprise 1.0 mang đến cho Vite và Rsbuild lớp tích hợp Symfony quen thuộc của Webpack Encore. Việc di chuyển vẫn là một dự án build cần kiểm kê, kiểm thử so sánh và chuyển đổi từng bước.

Symfony Reprise 1.0: di chuyển từ Webpack Encore sang Vite hoặc Rsbuild

Symfony Reprise 1.0 được phát hành ngày 26 tháng 8 năm 2026. Dự án cung cấp cho Vite và Rsbuild lớp tích hợp mà một ứng dụng Symfony cần: entry point, manifest, hàm Twig, máy chủ phát triển, Symfony UX, CDN và Subresource Integrity. Phiên bản 1.0 loại bỏ trạng thái thử nghiệm và đặt API công khai dưới quy tắc đánh phiên bản ngữ nghĩa cùng cam kết tương thích với Symfony. Điều này khiến Reprise trở thành ứng viên nghiêm túc để thay thế Webpack Encore, nhưng không phải là một quy trình di chuyển tự động.

Điểm cần nhớ: Reprise không phải là một bundler mới. Vite hoặc Rsbuild thực hiện việc biên dịch; Reprise tạo ra các tệp và quy ước mà Symfony mong đợi. Dự án giảm bớt ma sát khi di chuyển, nhưng bạn vẫn phải kiểm kê các hành vi của Encore, chọn bundler, kiểm tra các asset được sao chép, môi trường phát triển cục bộ, Symfony UX, cache và triển khai.

1. Reprise 1.0 thực sự ổn định điều gì

Việc phát hành Reprise 1.0 không tương ứng với việc bổ sung một danh sách dài các tính năng. Đây trước hết là một cam kết về tính ổn định. Theo thông báo của Symfony, API công khai hiện tuân theo quy tắc đánh phiên bản ngữ nghĩa và cam kết tương thích của framework: một thay đổi phá vỡ tương thích phải trải qua giai đoạn deprecated trước khi xuất hiện trong một phiên bản chính tiếp theo.

Điểm này quan trọng với các đội ngũ từng do dự khi xây dựng chuỗi asset trên một thành phần vẫn còn được giới thiệu là thử nghiệm. Các phiên bản trước chủ yếu tăng cường kiểm thử end-to-end, hỗ trợ tính toàn vẹn của tài nguyên con, playground và hướng dẫn di chuyển từ Encore.

Tuy nhiên, vẫn cần thận trọng. Symfony nói rõ rằng Reprise còn mới. Phiên bản 1.0 có nghĩa là giao diện công khai đã ổn định; điều đó không chứng minh mọi trường hợp đặc biệt xuất hiện sau nhiều năm của các dự án Encore đều đã được hỗ trợ. Một thử nghiệm trên ứng dụng thực tế vẫn là điều bắt buộc.

2. Một lớp Symfony, không phải đối thủ của Vite hay Rsbuild

Webpack Encore kết hợp cấu hình Webpack được đơn giản hóa với tích hợp chặt chẽ vào Symfony. Reprise áp dụng cách phân tách rõ ràng hơn. Vite hoặc Rsbuild đảm nhiệm TypeScript, Sass, PostCSS, JSX, Vue hoặc Svelte, chia nhỏ mã, source map, rút gọn và tải lại nóng. Reprise không triển khai lại các chức năng này.

Trách nhiệm của Reprise là tạo và đọc các quy ước hữu ích cho backend: entrypoints.json, manifest.json, phân giải các tệp có hash, hàm Twig, kết nối với máy chủ phát triển, quản lý nhiều bản build, sao chép tệp, hỗ trợ Symfony UX và tùy chọn thêm hash SRI.

Kiến trúc này tránh việc tạo ra một lớp trừu tượng hoàn chỉnh bên trên các bundler. Nó cho phép sử dụng tính năng gốc của chúng trong khi vẫn giữ trải nghiệm Symfony nhất quán. Đổi lại, bạn phải hiểu mỗi nhu cầu được cấu hình ở lớp nào. Alias JavaScript, plugin Vue hoặc tối ưu bundle thuộc về bundler; việc tạo các thẻ Twig và mối quan hệ với thành phần Asset thuộc về Reprise.

Cần ghi rõ sự phân biệt này trong tài liệu dự án để tránh cấu hình phân tán hoặc trùng lặp.

3. Lựa chọn giữa Vite và Rsbuild

Reprise hỗ trợ Vite và Rsbuild. Lựa chọn không nên chỉ dựa trên mức độ phổ biến hoặc một benchmark chung chung.

Vite có hệ sinh thái rất rộng, mức độ được sử dụng cao và trải nghiệm phát triển quen thuộc với nhiều đội frontend. Đây thường là lựa chọn tự nhiên cho các dự án Vue, React, Svelte hoặc JavaScript thông thường đã có plugin Vite.

Rsbuild dựa trên hệ sinh thái Rspack và hướng đến khả năng tương thích đáng kể với các cách sử dụng bắt nguồn từ Webpack, đặc biệt chú trọng hiệu năng build. Nó có thể phù hợp khi dự án có cấu hình phức tạp hoặc thói quen gần với Webpack hơn, với điều kiện kiểm tra từng plugin thực sự được sử dụng.

Hãy xây dựng một bài kiểm thử đại diện: một entry công khai, một entry quản trị, Sass, một vài dynamic import, một controller Stimulus, các asset được sao chép và một bản build production. So sánh thời gian khởi động, thời gian biên dịch, độ ổn định của HMR, kích thước đầu ra, khả năng tương thích của plugin và mức dễ đọc của cấu hình.

Bundler tốt nhất là bundler mà đội ngũ biết cách sử dụng, chẩn đoán và duy trì cùng các dependency của dự án.

4. Lập bản đồ hệ thống Webpack Encore hiện có

Trước khi thay đổi cấu hình, hãy kiểm kê mọi lệnh gọi Encore.* và mọi hành vi gián tiếp. Hướng dẫn chính thức của Reprise cung cấp đối chiếu theo từng phương thức, giúp công việc này dễ hơn, nhưng không thay thế việc phân tích kết quả cần đạt.

Hãy ghi nhận các entry point, chunk dùng chung, tệp tĩnh được sao chép, alias, biến môi trường, loader chuyên biệt, plugin, polyfill, controller Stimulus, package Symfony UX, các bundle có thể có và những đường dẫn được template hoặc mã PHP sử dụng.

Đồng thời kiểm tra việc triển khai: build được chạy ở đâu? Thư mục public/build có được giữ lại giữa các bước không? Hình ảnh có được gửi lên CDN không? Máy chủ có chờ entrypoints.json khi khởi động không? Các tệp có được preload hoặc chịu sự điều chỉnh của Content Security Policy không?

Phần lớn sự cố khi di chuyển không đến từ việc biên dịch JavaScript chính, mà từ một logo được sao chép vào đường dẫn ổn định, một worker, một font, một tệp dịch hoặc một script được tải bởi một trang hiếm khi được kiểm thử.

Hãy tạo ma trận «hành vi hiện tại / thành phần phụ trách / tương đương / kiểm thử xác nhận». Ma trận này sẽ trở thành hợp đồng di chuyển.

5. Di chuyển template, entry và Symfony UX

Trong trường hợp phổ biến, các helper Twig chuyển từ encore_entry_script_tagsencore_entry_link_tags sang các phiên bản tương đương reprise_entry_script_tagsreprise_entry_link_tags. Hình thức chung vẫn tương tự, nhưng kết quả sử dụng ES module và hoạt động của máy chủ phát triển phụ thuộc vào bundler được chọn.

Hãy bắt đầu bằng việc giữ nguyên tên các entry. Điều này hạn chế thay đổi trong template và cho phép so sánh từng trang. Đừng tận dụng việc di chuyển để đổi tên toàn bộ entry, sắp xếp lại thư mục và viết lại JavaScript cùng lúc.

Đối với Symfony UX và Stimulus, Reprise có thể đọc controllers.json và đăng ký controller cục bộ hoặc controller do package cung cấp. Tuy nhiên, hãy kiểm tra nhu cầu riêng của từng package: stylesheet hoặc asset được thiết kế cho Webpack loader có thể cần alias hoặc cấu hình phù hợp với Vite hoặc Rsbuild.

Các controller tải trì hoãn, dynamic import và thành phần Turbo phải được kiểm thử qua quy trình điều hướng hoàn chỉnh. Việc hiển thị lần đầu đúng không đảm bảo rằng thay đổi trang, modal hoặc form sẽ đặt lại trạng thái chính xác.

Các đội ngũ đồng thời hiện đại hóa bộ công cụ PHP có thể liên hệ công việc này với những thay đổi được mô tả trong bài viết của chúng tôi về Symfony Language Tools và LSP chính thức, đồng thời giữ các phần việc độc lập để đơn giản hóa chẩn đoán.

6. Bảo vệ manifest, CDN, cache và tính toàn vẹn

Reprise tạo entrypoints.jsonmanifest.json tương thích với nhu cầu của Symfony. Hãy kiểm tra rằng các tệp này được tạo trong mọi môi trường và có mặt trong artifact cuối cùng. Một image Docker được xây dựng qua nhiều giai đoạn có thể biên dịch asset rồi quên sao chép thư mục đầu ra.

Các tệp được tham chiếu trực tiếp từ Twig hoặc PHP phải nằm trong chiến lược sao chép và manifest. Theo mặc định, tên có hash giúp việc vô hiệu hóa cache dễ hơn. Có thể cần giữ đường dẫn ổn định cho favicon, web manifest hoặc hệ thống bên ngoài, nhưng khi đó phải bảo đảm CDN hoặc proxy tính đến query string dùng để versioning.

Với CDN, publicPath production và tiền tố của các key trong manifest phải khớp nhau. Hãy kiểm thử môi trường thực: origin, HTTPS, CORS, cache, nén và purge. URL đúng trong tệp không bảo đảm tệp đó thực sự đã được công bố.

Reprise có thể thêm hash Subresource Integrity cho script và stylesheet. Cơ chế bảo vệ này phù hợp trong production, nhưng phải phối hợp với các biến đổi được thực hiện sau build. CDN viết lại nội dung sẽ làm hash không còn hợp lệ.

Cuối cùng, hãy kiểm tra các thuộc tính cần thiết cho Content Security Policy, đặc biệt là nonce. Reprise cung cấp một event để tùy chỉnh các thẻ được tạo; điểm này phải được kiểm thử thay vì bổ sung sau khi chuyển đổi.

7. Tổ chức chuyển đổi từng bước

Cách di chuyển an toàn nhất bắt đầu bằng một branch riêng và một build song song. Tạm thời giữ output của Encore làm tham chiếu, sau đó tạo output của Reprise trong thư mục khác. So sánh sự hiện diện của entry, URL, asset được sao chép và kích thước tệp.

Tiếp theo, hãy tự động hóa kiểm thử render các trang chính và so sánh trực quan. Thêm các luồng Playwright bao phủ đăng nhập, form, thành phần tương tác, trang quản trị và các màn hình sử dụng entry chuyên biệt.

Pipeline phải chạy production build, kiểm tra sự tồn tại và tính hợp lệ JSON của manifest, rồi khởi động ứng dụng được xây dựng từ artifact cuối cùng. Chỉ kiểm thử máy chủ phát triển sẽ không phát hiện lỗi quên sao chép hoặc đường dẫn production.

Để triển khai production, hãy chuẩn bị phương án rollback khôi phục cả mã backend và các asset tương thích. Nếu triển khai dùng release nguyên tử, mỗi release phải chứa build riêng để tránh việc template cũ tải tệp của phiên bản mới.

Sau khi chuyển đổi, hãy theo dõi lỗi JavaScript, phản hồi 404 đối với asset, vi phạm CSP, cache trình duyệt và thời gian tải. Chỉ xóa Encore cùng các tệp cấu hình sau một thời gian quan sát và một đợt nghiệm thu đầy đủ.

Di chuyển asset Symfony từ Webpack Encore sang Reprise với Vite hoặc Rsbuild.
So sánh pipeline Encore/Webpack với quy trình di chuyển từng bước qua Reprise sang Vite hoặc Rsbuild.

8. Quyết định có nên di chuyển ngay hay không

Một ứng dụng Symfony mới có thể đánh giá Reprise ngay từ đầu, đặc biệt nếu đội ngũ đã thành thạo Vite hoặc Rsbuild. Phạm vi gọn của thành phần và cam kết tương thích 1.x hiện mang lại nền tảng dễ dự đoán hơn.

Với một ứng dụng Encore ổn định, việc di chuyển phải đáp ứng một nhu cầu: build nhanh hơn, hệ sinh thái frontend đơn giản hơn, đồng bộ nhiều dự án, giảm cấu hình Webpack đã trở nên khó quản lý hoặc áp dụng plugin hiện đại. Di chuyển chỉ vì có công cụ mới hơn sẽ tạo rủi ro mà không đem lại giá trị rõ ràng.

Mức độ nỗ lực phụ thuộc ít hơn vào số dòng trong webpack.config.js và nhiều hơn vào các quy ước đã tích lũy xung quanh build. Một dự án đơn giản có thể chuyển đổi nhanh. Một nền tảng nhiều entry với CDN, worker, thành phần cũ và extension tùy chỉnh cần một thử nghiệm đầy đủ.

Reprise 1.0 giảm bớt sự không chắc chắn về kỹ thuật. Nó không loại bỏ nhu cầu kiểm kê, nghiệm thu và kế hoạch rollback.

Kết luận

Symfony Reprise 1.0 là một bước quan trọng đối với các dự án muốn sử dụng Vite hoặc Rsbuild mà không mất đi sự tích hợp quen thuộc giữa asset và Symfony. Lựa chọn kiến trúc của Reprise hợp lý: để bundler biên dịch và chỉ cung cấp lớp kết nối cần thiết cho framework.

Một cuộc di chuyển thành công nên được thực hiện từng bước. Hãy lập bản đồ hành vi của Encore, kiểm thử cả hai bundler trên một trường hợp thực tế, trước hết tái tạo các entry hiện có, xác nhận manifest và triển khai, rồi mới hiện đại hóa cách tổ chức frontend. Partitech hỗ trợ nâng cấp Symfony, di chuyển công cụ và bảo mật chuỗi build cũng như triển khai.

Chia sẻ bài viết