こんにちは。エンジニアの佐藤(@t0m0h1r0x)です。
今回は、弊社で現在進めているEmotionからCSS Modulesへの移行について紹介します。
移行の背景、検討した代替ライブラリ、そして最終的な決定について話していきます。
移行の検討理由
弊社では現在、CSS-in-JSライブラリとしてEmotionを使用しています。ピュアなCSS記法を好むメンバーが多いので、EmotionのTagged Template Literal記法がチーム文化との相性も良く、これまで活用してきました。
一方で、フロントエンド開発フレームワークにNext.jsを採用しており、そちらではApp Routerへの移行を進めています。
App RouterのメリットはやはりReact Server Components(RSC)の活用だと思います。RSCはユーザー体験と開発者体験の向上につながる重要な機能ですが、2024年9月現在、その仕様上EmotionでRSCをスタイリングできません。
このような背景から、RSCに対応できる新たなCSSライブラリの検討を始めました。
代替ライブラリの検討
代替ライブラリの選定にあたっては、パフォーマンスやAPIの使い勝手といった要素も大切ですが、チームとの相性も重要な要件としました。特に、Tagged Template Literalをサポートしていて、Emotionとの書き心地に互換性があることをポイントとしました。
Panda CSS
Panda CSSはChakra UIのチームが開発しています。CSSの記法としてObject LiteralかTagged Template Literalを選択できますが、後者には機能制限があるようです。 詳細については 公式ドキュメントを参照してください。
Pigment CSS
Pigment CSSはMaterial UIのチームが開発しています。 こちらも要件と合致しそうなのですが、開発初期段階のためプロダクション利用には検討が必要です。 ちなみにPigment CSSは、最近リリースされたMaterial UI v6に、experimentalなopt-inとして組み込まれました。さらなる開発が期待できそうです。
CSS Modulesへの移行
上記の検討を踏まえ、弊社では一時的に信頼と実績があるCSS Modulesへの移行を決定しました。その理由は次の通りです。
- プロダクトとチームの要件に合致
- 他ライブラリへの将来的な移行が比較的容易
一方でCSS Modulesの採用にあたっては、特に次の点に留意しています。
- TypeScriptによる型定義
- 動的スタイリングの実装
- 仕様がメンテナンスモード
型定義にはHappy CSS Modulesを使用して、自動生成することで対応しています。
動的スタイリングについては、コード中にpropsベースのスタイリング実装が多くなかったことや、コンポーネントのルールを整備していたことで不要なcomponent targetingを予め減らせていたため、現時点では大きな支障は出ていません。
仕様についてはメンテナンスモードであるものの、長らくこの状態が続いていながら今の所大きな問題は起きていないため安定しているのではないかと思っています。
参考:
- Future of CSS Modules · Issue #187 · css-modules/css-modules · GitHub
- Interoperability across tools and support plain JS modules imports · Issue #1050 · webpack-contrib/css-loader · GitHub
今後の展望
CSSを取り巻く環境は日々進化しています。例えば、React v19からは<style>のホイスティングがサポートされる予定であり、それを活かしたRESTYLEというライブラリも登場しています。 このような状況を踏まえ、当面はCSS Modulesへの移行を進めつつ、新たなライブラリの登場にも注目していきたいと思います。
まとめ
EmotionからCSS Modulesへの移行は、弊社のフロントエンド開発環境を大きく変える重要な取り組みでした。 RSCとの互換性という課題はありましたが、暫定的な解決策を見つけつつ、より良い選択肢を模索し続けていきたいと思います。
弊社では一緒に働いてくれるメンバーを募集中です。興味を持っていただいた方は是非こちらのページからご応募お願いします。