Xin chào các bạn tôi là Yuji Suzuki của đội Technical Promotion.

Pixta thường sử dụng Ruby on Rails (dưới đây gọi tắt là Rails) như framework chính để phát triển application. Gần đây, chúng tôi đã chuyển đổi công cụ xây dựng tool xung quanh Javascript từ browserify sang webpack. Trong bài viết này, tôi muốn nói về lý do chúng tôi lựa chọn webpack, cách thức để đảm bảo cân bằng giữa webpack với Sprockets, và so sánh với webpacker –  một framework mới xuất hiện thời gian gần đây. Bài viết này hướng tới những đối tượng sau:

• Rails developer
• Người muốn ứng dụng Rails cho môi trường front-end hiện đại.
• Người muốn sử dụng đồng thời webpack và Sprockets
• Người gặp khó khăn hoặc chưa thể cài đặt webpacker.

Bối cảnh

Trong Rails, điển hình là JS, mọi người thường mặc định dùng Sprockets để quản lý file asset. Thời gian gần đây PIXTA cũng chuyển sang dùng Sprockets, cùng với Yarn và browserify để build tool và quản lý file. Tuy nhiên cách làm này vẫn còn tồn tại một số điểm hạn chế.

Vấn đề đầu tiên là tuy Sprockets đã được đưa vào sử dụng nhưng không phát huy tối đa hiệu quả của ecosystem xung quanh JS. Ngoài ra, tính tương thích của Infastructure xây dựng bằng browserify không cao.(1)
Tuy nhiên, điều này không có nghĩa chúng tôi sẽ ngừng sử dụng Sprockets hoàn toàn.. Chúng tôi đã áp dụng một số giải pháp hỗ trợ để giải quyết vấn đề đường dẫn như javascript_include_tag và quyết định vẫn tiếp tục sử dụng Sprockets.

Mặc dù browserify có vẻ đơn giản và dễ dàng để sử dụng hơn so với webpack nhưng vẫn một số hạn chế (2), trong khi đó càng ngày càng có nhiều công cụ phát triển dành cho webpack được ra đời.

Mặt khác, nói về webpacker, nếu bạn sử dụng cho Rails phiên bản 5.1 trở đi, nó có thể giúp bạn đơn giản hóa quy trình phát triển. Tuy nhiên, bạn lại không thể sử dụng nó trên các phiên bản Rails cũ hơn và khó có thể gỡ bỏ trong trường hợp gặp tight coupling…(3)

Sau khi phân tích như trên, chúng tôi đi đến quyết định sẽ không sử dụng browserify và webpacker đơn lẻ, mà sẽ tìm cách để có thể sử dụng song song webpack và Sprockets.

Ứng dụng webpack

Khi build, tôi đã thay thế Sprockets bằng webpack, và chỉ sử dụng Sprockets để giải quyết vấn đề đường dẫn của javascript_include_tag và stylesheet_link_tag .(Tham khảo sơ đồ dưới đây.)

Có thể thấy chức năng định hướng không có gì thay đổi, nhưng có khả năng sẽ gây ảnh hưởng tới JS của tất cả các trang. Chính vì thế, tôi sẽ release từng phần một để thu hẹp phạm vi ảnh hưởng.

Kết quả

Bằng cách build trên webpack, bạn có thể dễ dàng cài đặt các thành phần và có thể dễ dàng sửa chữa hay thay đổi sau đó. Cách build này không khác biệt nhiều so với cách build tiêu chuẩn của Rails nên bạn không cần thực hiện bất kỳ một thay đổi lớn nào.

Mặt khác, vẫn còn một điểm hạn chế khi build module trên webpack. Đó là bạn cần phải nắm được behavior của Sprockets như nén file hay cấp giá trị digest và tìm cách cài đặt webpack để có thể tái hiện được những behavior đó. Ngoài ra,  cách hoạt động của webpack có vẻ phức tạp hơn so với browserify, nên trước khi bắt đầu sử dụng bạn cần phải chia sẻ những điều cần chú ý cho các thành viên khác trong team của mình.

Kết luận

Nói tóm lại, qua bài viết này tôi muốn giới thiệu đến các bạn những điểm chính của webpack. Sau đây, chúng tôi sẽ tiếp tục tiến hành cải tiến khâu phát triển hệ thống ở PIXTA. Trong tương lai, chúng tôi muốn tạo hệ thống đo lường và cài đặt điều chỉnh.

PIXTA vẫn liên tục tuyển thêm các developer. Chi tiết mời các bạn tham khảo ở link sau nhé: https://pixta.vn/co-hoi-nghe-nghiep/

Chú thích

1. Ví dụ như khi bạn muốn quản lí phiên bản của uglify-js và nén file ở front-end. Nhưng bản đồ nguồn(source maps) lại không hoạt động tốt.
2. Ví dụ như muốn thêm plugin để xử lí CSS Module. Browserify cũng cung cấp nhiều plugin tương tự tuy nhiên chúng mới chỉ ở giai đoạn thử nghiệm.
3. Chúng tôi cũng lo ngại về sự tồn tại của webpack trong bối cảnh ngày càng có nhiều cộng cụ mới được ra đời điển hình có thể kể đến rollup, và webpack không thể theo kịp phiên bản update như plugin của grunt và gulp.