甘い香りに誘われて Vanilla Extractを1年間運用してみた ラクスル事業本部 ダンボールワン開発部　宮﨑 圭司 (@miyahkun) 2024.03.27 フロントエンド技術選定 ~ゼロランタイムCSS in JSとTailwind CSS編~ 社外公開 Public 

© RAKSUL, inc. All rights reserved. プロフィール 宮﨑 圭司 (Miyazaki Keiji) X, GitHub: @miyahkun 2021年 ラクスル新卒入社 吸収合併したダンボールワンという梱包資材ECの開発・運用を行う 趣味: ゲーム (League of Legends, Valorantなど)、ねこと戯れる 2 

© RAKSUL, inc. All rights reserved. ・諸々の背景 ・Vanilla Extractについて軽く紹介 ・技術選定をする上で考慮した観点 ・1年間運用してどうだった？ ・まとめ このLTで話すこと 3 

© RAKSUL, inc. All rights reserved. 背景 - 対象のサービス ・ネット印刷EC ・社内デザインシステムを運用 　ある程度のデザインルールがある 4 ・2023年にラクスルが吸収合併 ・ダンボールなどの梱包材EC ・これまでラクスルとは完全に独立した 　デザインルールで運用されてきた 今回はこちらがメイン✋ 

© RAKSUL, inc. All rights reserved. 背景 - サービス要件など ・2023年4月ごろからECサイトのフロントエンド部分を段階的に移行中 ・サイトの性質は参照系が多く、認証必須ページは少ない ・パフォーマンス要件はそこまで高くない ・ダークモード対応は将来的にも想定していない ・Next.js App Router (SSR), React Server Components (以下、RSC) を利用 ・Vanilla Extractを採用 5 

© RAKSUL, inc. All rights reserved. ゼロランタイムCSS in JS ビルド時にCSSファイルを生成 コンポーネントとは別ファイルで記述 例: Hero.css.ts “Sprinkles” 機能でUtility Classを定義できる Vite, Next.js, Astro など主要ツールを公式サポート Vanilla Extractとは 6 

© RAKSUL, inc. All rights reserved. JSランタイム環境が必須なツールはRSCで利用不可（例: Chakra UI） 技術選定の判断材料 7 吸収合併の関係でUIは徐々に変化 どんなUIを目指し、どんな時間軸で進めていくのかが不明確 ラクスル側のデザインシステムを利用するか、独自に進めるか ダンボールワン専任の正社員デザイナーが退職、業務委託1名だけに （今は専任デザイナーがいます！） 

© RAKSUL, inc. All rights reserved. 理想と現実、そこからの決定 8 理想 本当はデザイントークンを定義・運用したい（特に Color, Spacing, Typographyあたり） ライブラリは問わずUtility Firstで実装したい（Tailwind CSSやCSS in JSなど） 現実 吸収合併されたサービスであり、今後のUI方針で不確定要素が多い デザイントークンはエンジニアとデザイナーが協働して作っていくもの 当時はこれらを推進する余裕がなかった 柔軟にスタイリングできて CSS Modules よりも便利な Vanilla Extract を採用 （Linariaも有力候補だったが、正直どちらでも良かった） 採用候補 ・CSS Modules (w/ typed-css-modules) ・Tailwind CSS ・Linaria ・Vanilla Extract 

© RAKSUL, inc. All rights reserved. 9 あれから1年 

© RAKSUL, inc. All rights reserved. 強いて不満を挙げるなら Stylelintエコシステムの恩恵を受けられない(例: プロパティソート) (Next.js側の問題) ページ遷移時のちらつき、重複したスタイル定義 我々の導入方針 Vanilla Extractの多様な機能の中で、本当に必要なものしか使わない ・学習コストが低い（未経験でもオンボーディングが楽） ・ただのJavaScriptオブジェクトなので、IDE拡張機能が不要 Vanilla Extractに対する振り返り 10 利用しているAPIは4つだけ RSC起因の問題は特に無し ✅ 書き心地を一言で表すなら、Better CSS Modules 

© RAKSUL, inc. All rights reserved. Tailwind CSSは制約を導入するツール（例：デザイントークン必須、arbitrary valueは避けたい） 制約にはメリデメがある。デザイントークンを例に挙げると、 メリット：UIの細かい調整が減り、UIデータ作成・実装が高速に デメリット：一度定義したデザイントークンは変えにくい。2重管理はもっとツライ 最初から独自のTailwind CSSを導入していたら、今頃大変な思いをしていたかも 😌 ここからの学び 不確定要素が多い中で、最初に柔軟性を重視したことが、後からの制約を受け入れやすくなった 後からTailwind CSSを導入（現在進行中） 11 UI方針と組織体制が整い始めた。議論の末、 ラクスルのTailwind CSS製デザインシステムを 導入することに。 

© RAKSUL, inc. All rights reserved. アプリ側reset.css vs Tailwind CSS Preflight ページ内で特定のclassの子孫要素にだけTailwindのスタイルを適用 (例: .kamii-element) ・Preflightのスタイルを手動で上書き（おそらくpluginとして実現可能） ・①アプリ側のreset.css、②Tailwind Preflight の順で定義する ・tailwind.config.js の “important” を設定。 　.kamii-elenent 配下のみをTailwind CSSの有効範囲に remの基準が異なる アプリ側は 1rem = 10px、デザインシステム側は 1rem = 16px remを使用したスタイルが全て崩れる → tailwind.config.js で “theme” 設定を上書きして対応 後からTailwindを導入しデフォルトスタイルが競合 12 

© RAKSUL, inc. All rights reserved. 技術選定当時 ・フレームワーク・吸収合併・組織の観点を考慮してVanilla Extractを採用 1年後の現在 ・Vanilla Extract は “Better CSS Modules” のように使えている ・後から社内デザインシステムを導入し、Vanilla ExtractとTailwind CSSを併用 ・柔軟性を重視した技術選定が、後の選択肢を広げた まとめ 13 

© RAKSUL, inc. All rights reserved. 14 https://techblog.raksul.com/ RAKSUL TechBlog 社員インタビュー https://recruit.raksul.com/story/archives/engineer/ RAKSUL 公式connpass https://raksul.connpass.com/ https://www.youtube.com/channel/UCyihWcvrHmE e-edcqdcJFsQ/ RAKSUL 公式YouTube RAKSUL 公式Ｘ https://twitter.com/raksuldev RAKSUL をもっと詳しく RAKSUL 紹介 https://speakerdeck.com/raksulrecruiting/raksul-introduction