Từ giờ chỉ còn ESM mà thôi.

Trước đây tôi vẫn hoài nghi về việc chuyển mọi thư viện JavaScript sang ESM một cách quá nhanh. Nhưng hiện nay, khi công nghệ và mức độ phổ biến liên quan đến ESM đang phát triển từng ngày, tôi mong mọi lập trình viên đều sẽ chuyển sang ESM. Lý do như sau.

Lý do

• Công cụ đã sẵn sàng
  • Đã có rất nhiều công cụ như Vite, ESLint, tsx có thể giúp việc chuyển sang ESM dễ dàng hơn.
  • Cách làm thư viện hiện có (CJS) khó có thể phụ thuộc vào ESM, vốn là phương thức hiện đại hơn, nên chúng ta cần tiến lên phía trước để phát triển trong tương lai.
  • Trong Node.js hiện đại, đã có cách tải thư viện ESM bằng hàm require(), giúp việc áp dụng ESM trở nên dễ dàng hơn.
• Vấn đề hỗ trợ kép
  • Do khác biệt trong thiết kế của hai cách tiếp cận là rất lớn nên khả năng tương thích lẫn nhau giảm đáng kể.
  • Người dùng sẽ phải mất công kiểm tra từng cái xem có hỗ trợ ESM hay không.
  • Vì phải hỗ trợ cả hai cách nên kích thước gói trở nên rất lớn.

Khi nào nên chuyển?

• Với gói mới, hãy chuyển sang ESM ngay từ đầu.
• Với thư viện hướng đến trình duyệt, bạn có thể tạo ra bundle nhẹ hơn.
• Ngay cả với chương trình CLI, người dùng của nó cũng có thể tự nhiên chuyển sang ESM.
• Nhưng trước đó, điều quan trọng là phải hiểu trạng thái của các thư viện mà bạn đang phụ thuộc vào và yêu cầu của người dùng.

Cần chuyển đến mức nào?

Để nắm được các phụ thuộc của thư viện, tôi đã tạo ra trình phân tích phụ thuộc. Bạn có thể xem trạng thái của các thư viện đang phụ thuộc và cả tác động khi chuyển sang ESM.

Việc sắp tới

Tôi dự định sẽ dần chuyển các gói mà mình đang duy trì sang ESM và xem xét kỹ các phụ thuộc. Ngoài ra, tôi cũng đang chuẩn bị nhiều ý tưởng thú vị với node-modules-inspector để cung cấp những góc nhìn hữu ích hơn và tiếp tục hỗ trợ việc tìm ra phương án tốt nhất.

Tôi kỳ vọng vào một hệ sinh thái JavaScript/TypeScript nhẹ hơn, linh hoạt hơn và được tối ưu tốt hơn. Hy vọng điều này hữu ích.