これからは ESM 一択です。
(antfu.me)少し前まで、私はすべての JavaScript ライブラリを急激に ESM へ移行する流れに否定的でした。ですが、現在は ESM 関連の技術やその比重が日ごとに発展しているため、私はすべての開発者がぜひ ESM へ移行してほしいと考えています。理由は次のとおりです。
理由
- 整ったツール群
- Vite、ESLint、tsx など、ESM への移行を助けてくれる多くのツールが登場しました。
- 従来のライブラリ方式(CJS)が最新方式である ESM に依存するのは容易ではないため、今後の発展のためには前へ進む必要があります。
- 最新の Node.js では、ESM ライブラリを
require()関数で読み込む方法が開発されており、ESM をより導入しやすくなっています。
- 二重サポートの問題
- 2 つの方式は設計上の違いが大きいため、相互運用性が大きく損なわれます。
- ユーザーが ESM 対応の有無を一つひとつ確認しなければならない煩わしさが生じます。
- 2 つの方式をサポートしなければならないため、パッケージのサイズが非常に大きくなります。
いつ変えるべきか
- 新しいパッケージは無条件で ESM に移行してください。
- ブラウザ向けのライブラリであれば、より軽量なバンドルを作れます。
- CLI プログラムでも、これを使う人たちが自然に ESM へ移行できます。
- ただしその前に、現在依存しているライブラリの状態とユーザーの要件を把握することが重要です。
どれくらい変えるべきか
ライブラリの依存関係を把握するために、依存関係アナライザー を作りました。依存しているライブラリの状態や、ESM に移行した場合の影響まで確認できます。
今後やること
私は、自分が管理しているパッケージを段階的に ESM へ移行し、依存関係を詳しく見ていくつもりです。また、node-modules-inspector を使った興味深いアイデアも数多く準備しており、より有用なインサイトを提供し、今後も最善の方法を見つける助けになるはずです。
私は、より軽量で、柔軟性が高く、最適化された JavaScript/TypeScript エコシステムに期待しています。役に立てば幸いです。
まだコメントはありません。