스크립트
00:00:00ShadCNがTailwindの最大の課題を解決するため
00:00:04新しいリンターをリリースしました。デザインシステムです。AIエージェントの台頭に伴い、
00:00:09Tailwindでルールを強制する優れた方法がなく、意図しないスタイルを
00:00:13AIが追加してしまう経験をした方も多いはずです。
00:00:17それがStarLexのような代替手段へ移行する大きな理由でしたが、ShadCNが解決策を出しました。
00:00:21Tailwindのデザインシステム向けに作られたエージェントファーストなリンターです。早速見ていきましょう。
00:00:29まずはこのリンターが実際に何をするのかから始めましょう。Tailwindではクラス名は単なる文字列であり、
00:00:34TypeScriptはそれ以上何も強制しません。つまり、パディングを独自に持つボタンに対して
00:00:38上書き用のパディングを指定できてしまいます。すでにテーマカラーを使用しているコンポーネントに
00:00:43「bg-pink-500」のようなランダムな色を追加したり、デザインシステムに12から16までの
00:00:48スペーシングスケールがあるにもかかわらず、13pxのような任意の値を指定したりできてしまいます。
00:00:53現在、これらはコードベースでエラーを引き起こさず、
00:00:58実際にコードをレビューするか、別のエージェントにレビューさせるためのルールを
00:01:02Markdownファイルに大量に追加するくらいしか検出方法がありません。しかしMarkdownは制約を強制するのが苦手です。
00:01:07リンターほど厳格にはできません。ShadCNは実際に数値を出しています。「削除ボタンを追加、
00:01:12デザイン上はピンクで角丸にする」「モックに完全に一致する統計カードを作成、
00:01:16パディング13px、角丸10px」「料金カードを目立たせる」といった、
00:01:22エージェントにシステムを無視させたくなるような8つのタスクを設定しました。ご覧の通り、
00:01:27どのモデルもこれらのタスクを実行するとデザインシステム違反を多発させましたが、
00:01:31このリンターを使用すると違反はゼロになりました。リンターの効果がわかったところで、使い方を見ていきましょう。
00:01:36これはOxlintやESLint用のプラグインで、Tailwind v4のプロジェクトであればどれでも動作します。
00:01:41ShadCN UIを使っている必要もありません。「no-restyle, but allowing layout」というルール1つから始められます。
00:01:47これは要するに、ページ側でmargin、width、flex、hiddenなどを指定して
00:01:51コンポーネントを配置することは許可されますが、スタイルの再定義は許可されないという意味です。
00:01:56つまり、padding、color、typography、shape、effects、motionなどは追加できません。追加しようとすると、このようなエラーが投げられます。
00:02:02「Buttonでp-4は許可されていません。余白はButton側で管理しています。デフォルトのsizeを使用するか、
00:02:07ここにmarginを指定するか、親要素にgapを指定してください。デザインシステムで明確に要求されている場合のみ
00:02:11コンポーネントにsizeを追加してください」といった内容です。このエラーメッセージの素晴らしい点は、
00:02:15サイズ一覧のようなものがリンターによって直接定義されているわけではないことです。
00:02:19ボタンコンポーネント自体のCVA設定を実際に読み取っているのです。そのため、新しいサイズを追加すれば、
00:02:24エラーメッセージにもそれが選択肢として提示されます。スタイルを再定義できるほぼすべてのTailwind機能についても同様です。
00:02:29ここに色を追加しようとすると、コンポーネントで定義されたものしか使えないと通知されます。これによる利点はもちろん、
00:02:33非常にわかりやすいエラーメッセージが得られ、エージェントがそれを読んで修正方法を理解できることです。
00:02:37何が正しいかを理解するためにデザイン全体のMarkdownファイルを読み込む必要がないため、
00:02:41トークン使用量の節約にもなります。リンターが非常に具体的なヒントを出してくれるからです。
00:02:45以上が最初のルールである「no-restyle」の基本的な使い方ですが、自分のデザインシステムに合わせるための
00:02:50カスタマイズ機能が豊富に用意されています。それについては後ほど戻るとして、まずは
00:02:54残りの5つのルールを見ていきましょう。全6つのルールがあります。「no-raw-colors」は
00:02:58「bg-pink-500」のような直接指定や、存在しない色、スペルミスの使用を防ぐためのルールです。
00:03:03テーマ内で定義された色である必要があり、これも何が許可されているかを直接伝えることで
00:03:08エージェントを助けます。これはSVGでも機能するため、pathに直接フィルの値を指定しようとすると、
00:03:13テキストカラーのクラスとともにcurrentColorを使用するようにというエラーが出ます。次は「no-arbitrary-values」です。
00:03:18名前の通りの機能を果たします。角括弧内に「p-[13px]」のような値を指定すると、
00:03:24「ハードコードされた非トークン値です。代わりにスケール上で同じ値となる p-3.25 を使用してください」と警告されます。
00:03:30また、角括弧内の「rounded-[10px]」のようなものは、「代わりに rounded-lg を使用してください」となります。
00:03:35radiusトークンを実際に読み込んで、それが10pxに相当する値だと知っているからです。
00:03:40このルールがデザインシステムを理解している最もクールな例の1つは、ランダムな背景色を
00:03:44設定しようとしたときに、最も近いテーマのトークンをエラーで教えてくれることです。
00:03:49これはエージェントにとって非常に良いコンテキストになります。残りのルールはほぼ説明不要でしょう。
00:03:54インラインスタイルを防ぐルール、不明なクラスの使用を防ぐルール、
00:03:57そして静的なクラスを強制するルールです。これは興味深いもので、テンプレートリテラル内の動的なものだと
00:04:02リンターがそのクラスが何になるか判断できません。
00:04:06そのため、このルールはそれらの扱い方を変えるよう促し、
00:04:09リンターが効果的に機能し続けられるようにします。以上が6つのリンタールールですが、
00:04:13先ほど述べたように、ご自身のデザインシステムに適合させるための
00:04:16高度なカスタマイズ性があります。ここで「コントラクト」を使用します。これはコンポーネント名に対する正規表現で
00:04:21マッチするコンポーネント単位のルールで、例えばこの設定では、CardTitleのタイポグラフィは変更できるが
00:04:25フォントファミリーやウェイトは変更不可、CardContentはスペーシングは変更できるが
00:04:30タイポグラフィは不可、と指定しています。これにより、Titleへのtext-lgの指定はエラーなしで通過し、Contentへのp-6も
00:04:36通過しますが、Titleのウェイトを変更しようとすると期待通りエラーになります。
00:04:41これらの設定におけるもう1つの優れたオプションはカスタムメッセージです。すべてのルールとルールの種類で、
00:04:45実際のコードから補完されるプレースホルダー入りのメッセージを受け取ることができます。そのため、私のButtonコントラクトでは、
00:04:50レイアウトのために「widthはButtonではなく親コンテナに設定すること」、また
00:04:55「paddingはButton側で管理しているため、サイズのテンプレートとともにButtonのsizeを使用すること」とメッセージを設定しました。
00:04:59これらは自身のデザインシステムから自動挿入されます。グローバルノートも設定できるため、
00:05:04すべての検出項目にこのメッセージを末尾に追加できます。これはエージェントに追加のヒントやコンテキストを与え、
00:05:08ドキュメントやガイドラインの場所を伝えるのに便利です。すでにデザインシステムが
00:05:12導入されている場合、このリンターを使い始めるには自社システム向けに設定する必要があるため、
00:05:16少し追加の手間がかかるかもしれませんが、大半のデザインシステムに対応できる十分な柔軟性があり、
00:05:20導入の際にはAIエージェントが助けてくれるはずです。最後に話しておきたいのは、
00:05:25このリンターにできないことです。プレーンCSSは検出できません。グローバルCSSファイルや@applyの中に
00:05:30生の指定がある場合、それに関するルールは強制できません。また、親セレクターを子まで追跡することはできず、
00:05:36同一ファイル内かつ1ホップまでのクラス値しか追跡しません。そして真新しいテーマのトークンは
00:05:40定義上システム内にあるとされるため、ルールを回避するためにデザインシステムへ勝手に色を追加する
00:05:46ようなエージェントの操作も、リンターは通過してしまいます。つまり、エージェントが追加している
00:05:50トークンやバリアントは人間がレビューし続ける必要があります。リンターはルールをチェックできるだけで、
00:05:54新しいオレンジ色が本当にデザインシステムに相応しいかを判断することはできません。確認するのは依然として人間ですが、
00:05:59このリンターによってその余分な作業のいくらかが削減されるはずです。導入を検討している場合に
00:06:03考慮すべきもう1つの点は、コンポーネントAPIがルールを強制できるほど十分に厳格かどうかです。
00:06:08ボタンが単に任意のクラス名を受け取るだけでバリアントを持たない場合、リンターが提案できるものはありません。
00:06:13したがって、実際にデザインシステムが整っており、実際のバリアントを使用していることが前提条件となります。
00:06:18正直なところ、ShadCN UIを使っていればすでに満たしているため、ほとんどの人は問題ないでしょう。
00:06:22最後のデメリットは、現時点ではOxlintとESLintでしか利用できないことです。Biome用の
00:06:27プラグインはまだありませんが、GitHubでオープンIssueになっているため、近いうちに登場することを期待しましょう。
00:06:31以上が新しいShadCN Linterです。デザインシステムを強制するのに役立つ6つのルールで、
00:06:36AIがコードの大半を書く現代において非常に役立ちます。これが皆さんの抱えていた問題を解決するか、
00:06:41それともStarLXなどの代替手段への移行をまだ検討しているか、気になるところです。
00:06:45下のコメント欄で教えてください。チャンネル登録もよろしくお願いします。それではまた次回お会いしましょう。
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기