name

material-symbols-add-framework

description

material-symbols-svg モノレポ内でフレームワーク向け package を追加または調整するための skill。新しい UI フレームワーク対応を追加するとき、既存 package の実装パターンを別フレームワークへ移植するとき、または React / Vue / Astro / Svelte / React Native 間で exports、アクセシビリティ、style handling、tests、CI、generator templates、docs、publish metadata の実装差分を埋めたいときに使う。

Material Symbols Add Framework

新しいフレームワーク向け package は、独自仕様を増やすのではなく既存 package のパターンに合わせて追加する。まず最も近い既存 package と比較し、その後 runtime behavior、exports、アクセシビリティ、tests、docs、CI、publish metadata まで揃っているか確認してから完了とする。

進め方

編集前に比較対象となる package を決める。
- TS / render-function 系は packages/react と packages/vue を起点にする。
- コンパイル系コンポーネントは packages/svelte と packages/astro を起点にする。
- モバイル系は packages/react-native を起点にする。
- この repo 内で挙動が揺れているか判断が曖昧な場合は、Lucide を第二の参照先として使う。特に decorative icon の既定動作、accessible icon の公開条件、slot / children の扱い、import surface の設計を確認する。
- 具体的な確認項目は references/checklist.md を読む。
実装前に、どこまで揃えるかを比較して把握する。
- generator support、package exports、README examples、runtime props、アクセシビリティ既定動作、test strategy、publish metadata を編集前に見ておく。
- 最初に動く実装ができた時点で止めない。利用者が実際に import、render、test、publish できる面まで他 package と揃っているか確認する。
generator と package entry point をまとめて更新する。
- scripts/templates/<framework>-template.ts を追加または更新する。
- scripts/generate-icons.ts と scripts/generate-exports.ts がその framework を認識する状態にする。
- 専用の build:* や publish:* が必要なら root package.json の scripts も更新する。
- package の exports は近い framework 群の package に合わせる。
runtime behavior を既存 package に揃える。
- size、color、fill の意味を他の icon package と合わせる。
- caller が custom style を渡しても color が失われないようにする。
- web package では decorative icon をデフォルトで hidden にし、accessible props や child content がある場合だけ公開する。
- React Native では default の accessibility exposure を強制せず、明示的な props のみ forward する。
- slot / children の扱いは明示的に確認する。child content を受け取れる framework なら、アクセシビリティ判定と render path の両方がそれを考慮している必要がある。
clean checkout でも成立する tests を追加する。
- isolated logic には helper test、user-visible behavior には component render test を優先する。
- test から src/w400 や生成済み icon module を import しない。
- createMaterialIcon(...) や同等の local fixture component を使い、CI が prebuilt artifact に依存しないようにする。
- CI は生成物の残骸も local build cache も無い clean checkout だと考える。
docs、CI、publish metadata を揃えてから完了にする。
- public surface が変わる場合は package README の usage examples と root README を更新する。
- package の files は最小限に保ち、他の publish 対象 package と揃える。
- ユーザーが明示しない限り、root の PR CI は pnpm test と pnpm lint を前提にする。

確認

まず package-local の確認を行い、その後 root の pnpm test と pnpm lint を実行する。
GitHub Actions で失敗して local では通る場合は、CI runner が clean checkout で動いている前提で、generated-file import や local build artifact の残りを疑う。
完了と判断する前に、references/checklist.md を section ごとに見直し、exports、a11y、docs、publish metadata の取りこぼしがないことを確認する。
publish 前に package.json の exports、files、README examples を再確認する。

Material Symbols Add Framework

進め方

編集前に比較対象となる package を決める。

TS / render-function 系は packages/react と packages/vue を起点にする。
コンパイル系コンポーネントは packages/svelte と packages/astro を起点にする。
モバイル系は packages/react-native を起点にする。
この repo 内で挙動が揺れているか判断が曖昧な場合は、Lucide を第二の参照先として使う。特に decorative icon の既定動作、accessible icon の公開条件、slot / children の扱い、import surface の設計を確認する。
具体的な確認項目は references/checklist.md を読む。

実装前に、どこまで揃えるかを比較して把握する。

generator support、package exports、README examples、runtime props、アクセシビリティ既定動作、test strategy、publish metadata を編集前に見ておく。
最初に動く実装ができた時点で止めない。利用者が実際に import、render、test、publish できる面まで他 package と揃っているか確認する。

generator と package entry point をまとめて更新する。

scripts/templates/<framework>-template.ts を追加または更新する。
scripts/generate-icons.ts と scripts/generate-exports.ts がその framework を認識する状態にする。
専用の build:* や publish:* が必要なら root package.json の scripts も更新する。
package の exports は近い framework 群の package に合わせる。

runtime behavior を既存 package に揃える。

size、color、fill の意味を他の icon package と合わせる。
caller が custom style を渡しても color が失われないようにする。
web package では decorative icon をデフォルトで hidden にし、accessible props や child content がある場合だけ公開する。
React Native では default の accessibility exposure を強制せず、明示的な props のみ forward する。
slot / children の扱いは明示的に確認する。child content を受け取れる framework なら、アクセシビリティ判定と render path の両方がそれを考慮している必要がある。

clean checkout でも成立する tests を追加する。

isolated logic には helper test、user-visible behavior には component render test を優先する。
test から src/w400 や生成済み icon module を import しない。
createMaterialIcon(...) や同等の local fixture component を使い、CI が prebuilt artifact に依存しないようにする。
CI は生成物の残骸も local build cache も無い clean checkout だと考える。

docs、CI、publish metadata を揃えてから完了にする。

public surface が変わる場合は package README の usage examples と root README を更新する。
package の files は最小限に保ち、他の publish 対象 package と揃える。
ユーザーが明示しない限り、root の PR CI は pnpm test と pnpm lint を前提にする。

確認

まず package-local の確認を行い、その後 root の pnpm test と pnpm lint を実行する。

GitHub Actions で失敗して local では通る場合は、CI runner が clean checkout で動いている前提で、generated-file import や local build artifact の残りを疑う。

完了と判断する前に、references/checklist.md を section ごとに見直し、exports、a11y、docs、publish metadata の取りこぼしがないことを確認する。

publish 前に package.json の exports、files、README examples を再確認する。