多くのCSSコードを書くと、複数のエラーが発生する可能性があります。 CSSの書き込みエラーを防ぐために、いくつかのツールが必要になる場合があります。
たぶん、時々あなたの間違いは本当にバグです。また、不整合または不明確なコードスタイルが単に性急に引き起こされる可能性もあります。たぶん、それらの多くは些細なように見えるかもしれませんが（あなたの性格に応じて）、コードベースが成長し、時間が蓄積するにつれて、多くの人がそれらを使用するときに醜いものを作るでしょう。物事の結果は、あなたが想像できるものではありません。
あなたは自分自身をコントロールしようとします。あなたの同僚は、あなたがあなたの間違いをタイムリーに修正できるときにもあなたを助けます。しかし、あなたとあなたの同僚はどちらも間違いのメーカーであるため、最終的には少なくともある程度は必然的に失敗しています。その後、あなたまたは他の人は、ページのCSSエラーによって引き起こされる問題を解決します。
あなたもあなたの同僚も、それが恥ずかしいのであなたが犯した間違いについて議論するのは好きではありません。それは時々イライラしたり、感情的に破裂したりすることさえあります。特定の仕様は、一貫したライティングスタイルなど、コードベースのメンテナンスに役立つ場合があります。そうでなければ、彼らはあなたのいつもの愛の要素を見せびらかすことと頑固さを示します。
さらに、コードがレビューされるのを待つ代わりに、エラーを指摘し、自分でそれらを変更し、そのようなエラーが再びそのエラーがないことを宣言するのではなく、タイムリーな方法でエラーを修正することを好む場合があります。 CSSエラーが発生すると、タイムリーなフィードバックは時間を節約できます。
必要なのは、エラーを防ぐマシンです
エラーが発生し、CSSを理解し、あなたを理解できるマシンが必要です。あなたの意図、好み、アイデア、および弱点です。
このようなマシンには制限があります。すべてが完璧ではありません。しかし、この制限はあなたやあなたの同僚とは異なります。エラーを防ぐことができる限り、それは疲れを知らずに動作し続けます。同時に、あなたとあなたの同僚は常にマシンを改善し、その機能を拡大し、その制限を弱めることができます。それはオープンソースであり、世界中の人々が参加して自分の役割を果たすことができます。
他の人と同様に、CSSの著者はリナーが必要です
エラーを「リナー」を防ぐこれらのプログラムを呼び出します。 JavaScriptにはいくつかのより良いリンダーがあります。特にエスリントは奇跡的に機能し、良いリナーがとても便利であることを示しています。しかし、CSSでは、私たちはそれほど幸運ではありません。私たちの選択は非常に限られています。特別な前処理者と以前のCSS Lintを備えたRubyベースのSCSS-Lint。
しかし、これはPostCSSが登場する前のすべてでした。さらに、POSTSSは、よりインタラクティブなCSSツールを構築するためのいくつかの方法を提供します。分析と操作のために、CSSクラスの構文を抽象的構文ツリー（AST）プラグインに解析できます。また、カスタムパーサーを使用すると、PostCSSは不規則な無効なパターンを処理することもできます（ //コメントなど）
成熟条件は、ポストCSSを搭載し、SCSS-LINTとESLINTの最良の機能に触発された、より強力な機能を備えたリナーをすでに生成できます。
私はこのプロジェクトで何人かの友人と協力しましたが、今、私たちが開発したツール、Stylelintの紹介を始めます。
StyleLintでできること
以下は、100を超えるルールとスケーラビリティを備えたStyleLintで試した関数の要約です。
この時点で、少しイライラしていることに気付いた場合（「OK、OK：Stylelintには奇跡的な仕事効果があると思います。要約はあまり必要ありません。」）。次のセクションにスキップするだけです。ここでは、いくつかの問題を説明し、いくつかのヒントを与えています。
エラーキャプチャ
いくつかのStyleLintルールは、あなたの動揺やぼんやりした目によって作成された綴りのエラーや省略など、明らかな間違いを特定するように設計されています。たとえば、空白のブロック、無効な16進数、重複したセレクター、無名のアニメーション名、間違った線形勾配構文を無効にすることができます。
他のルールは、より微妙な間違いをキャッチするために最善を尽くすことです。ルールを次に示します。プロパティのピア（ margin-topなど）をオーバーライドできる略記プロパティ（ marginなど）を使用する場合、これはあなたの過失によって引き起こされる可能性があるため、警告が発行されます。さらに、あなたに警告する別のルールがあります：カオスが発生したとき、ルールaがルールbの前に表示される場合、実際にルールbをカバーします。これは、ルールaのセレクターが優先度が高いためです（例えば、ルールaは.foo.bar{・・・}であり、ルールbは.foo{・・・}です）。これは非常に難しい状況です。
また、PostCSS doiuseプラグインを使用して、ブラウザがこのスタイルをサポートしているかどうかを確認するルールもあります。別のものは、CSS-Colorguardプラグインを使用して、使用を混乱させないように色の類似性を求めます。 （注：これは、PostCSSに基づくStylelintの主な利点の1つです。他のPostCSSプラグインと比較して、StyleLintはほとんど努力して促すことができます。）
ベストプラクティスを実施します
StyleSheetsでシステムメソッドを使用する場合、またはコードのスタイルガイドがある場合は、これらのパターンを禁止する必要があります。 StyleLintはすでにこれらの機能を提供しています。
まず、セレクターを強く制御する必要があります。 Stylelintを使用すると、特定の特異性を超える選択者を無効にしたり、営巣の深さに制限を設定したりできます。カテゴリセレクター（IDのないセレクターなど）を無効にし、正規表現を使用して、残りの部分の規則を命名できます。
!important 、またはブラウザがサポートしていないブラウザハックの使用を禁止できます。 Autoprefixerを使用している場合（または必要な場合）、ソースStyleSheetでベンダープレフィックスの使用を無効にすることができます。
より厳密になりたい場合 - 絶対的な一貫性を確保するために構成に時間を費やすことができます - StyleSheetプロパティの順序を実施し、ブラックリストとホワイトリストにプロパティ、値、関数、およびユニットを提供できます。
コードスタイルのコンベンションを実行します
Stylelintにはコードスタイルを自動的に実行するための規則があるため、あなたとあなたのチームメイトは積極的にセットアップする必要はありません。私たちは、これらのルールをより包括的かつ柔軟にすることを約束しています。
これらのルールは主にスペースを対象としていますが、引用符、上品および小文字と小文字などのその他の詳細も、小数の前にゼロを書く、キーワードの使用、値の綴りなども目的としています。
あなたとあなたのチームメイトがフォーマットコンベンションを確立できること（たとえば、コロンを宣言した後は常にスペースを離れます）を夢見て、それをStyleLint構成で変更することができます。機械王国で実行してください。
すべてを開発して拡張します
Eslint（およびCSS Lint）の作成者であるNicholas Zakasは、Eslintの成功がそのスケーラビリティにあることについて書きました。 StylelintはEslintのリードに従うことを試み、CSSの著者にリナーを提供しますが、これも拡張可能です。
独自のルールプラグインを作成および公開できます。今、私たちは多くのものを使用しています。そして、私たちは他の人の優れたプラグインを見たいと思っています。
構成は拡張可能であるため、共有できます。プラグインに関しては、Eslintのこの機能の価値について学びました。 WordPressおよびSuitCSS構成を含むことを確認し、公開されています。
StyleLintの組み込みのヒントが気に入らない場合は、手で独自のスタイルを作成したり、組織用に作成したりすることもできます。警告メッセージの提供に使用されるルールをカスタマイズすることもできます。
Stylelint APIを使用して、テキストコンパイラ用のプラグインを作成し、テストを実行して、Stylelintをワークフローのあらゆる側面に組み込むことができます。
Stylelint拡張機能についてのアイデアがある場合は、お知らせください！
予想される質問への回答
あなたの心にはいくつかの質問があるかもしれません。最も一般的な説明のいくつかを次に示します。
SCS以下でStyleLintを使用することは可能ですか？
答えはイエスです。SCSSでStylelintを使用でき、それも少ないことでサポートされています！ PostCSSはカスタムパーサーを許可するため、StyleLintはさまざまな非標準的な構文を簡単にサポートできます。PostCSSパーサーを解析することができます。
PostCSSパーサーのために、StylelintはSCSS、少ない、新しい砂糖をサポートしています。別のカスタム構文サポートを実装したい場合は、Postlessでそれを行うことができます！
もちろん、標準以外の構文（SASS IDセレクターの#{$interpolation}など）に拘束される特定のルールがあります。 Stylelintは私たちのスタイルシートのスタイルをカバーしようとしているため - 一部の人々は標準のCSSを使用し、一部の人々はSCSなどの拡張言語を使用し、一部の人々は奇妙なカスタムプロパティなどを使用します。しかし、私たちは見つけたこれらのエラーを扱ってきました。この期間中のルールは、列ごとのスタイルシートまたは列ごとのスタイルで完全に閉鎖または無効にすることができます。
Stylelintは将来のCSS構文を使用できますか？
はい！上記の答えと同様に、Stylelintは、PostCSSが理解していることを理解できます。実際、一部のStyleLintルールは、将来のCSS構文といくつかのカスタムプロパティを特に扱っています。
StyleLintの構成は巨大ですが、どこから始めればよいですか？
3つの構成方法をお勧めします。
公開された構成を拡張します。ユーザーが固有のベンチマークを提供できるようにするために、Stylelint-Configuration標準を維持します。そして、多くの構成が発表されています。ゼロから始めて、一度に1つのルールを追加します。デフォルトでは、ルールがオンになっているため、ルールを手動で追加することで、どのルールが実施されるかがわかり、追加する各ルールを理解できます。コピーパステ構成を開始し、使用するオプションを決定し、選択的に削除します。
ありがたいことに、巨大なStyleLint構成を何度も何度も書く必要はありません。好きなスタイルを選択でき、どこでも使用できます。
StyleLintを実行する最も簡単な方法は？
ほとんどの人にとって、最も簡単な方法は、そのコマンドラインを使用することです。
Gulpプラグインを好む場合は、Gulp-Stylintingを使用できます。 Webpackには、選択には多くの可能性があります。これらのプラグインが、Gruntのような他のStyleLintプラグインを作成するように促すことを願っています。 （オープンソースプロジェクトで検索できます！）
PostCSSプラグインを使用してStyleLintを実行することもできます。つまり、PostCSS（ほぼすべてのコンパイルツールをカバーする）を使用できる場所でStyLelintを使用できることを意味します。
さらに、Atom、Sublime Text、VSコード用のStyleLint Text Compilationプラグインも最速のフィードバックを提供します。詳細については、StyleLint Webサイトの補完ツールのリストを参照してください。
以下に示すように、コマンドラインでは、あなたが見ると予想している結果：
Atomで次のように表示します。
stylelintは私のエラーを修正できますか？
いいえ、しかし、StyleFMTと呼ばれる別のものはこれを行うように設計されています。 Lintingで使用するものと非常によく似たStyleLint構成が必要であり、エラーを修正できます。コミュニティのスタッフが貢献するにつれて、StyleLintがStyleLintルールに違反するエラーを自動的にパッチするために進化できることを願っています。彼らがこの目標を達成するのを手伝ってください！
また、CSSCOMBやStyLELINTと組み合わせて使用されるPerfectListなどの他のツールを使用して、自動的に修正して自動的に強制的に強制することもできます。
制約サプリメントには糸くずを使用します
優れたCSSには膨大な制約があります。だからこそ、SMACS、ACSS、BEM、SutCSS、ITCSSなどの方法について多くの時間を費やしています。悪いCSSを書くことは非常に簡単であることがわかっているため、CSSスタイルのライティングを恐れなくなると、仕事でインテリジェントな戦略を確立し、それに勇敢に固執する必要があります。
StyleLintの目標は、実行を自動化することです。これは、一連のコアルールと、CSSの著者が独自の戦略を実行するために使用できるプラグ可能なフレームワークを提供することです。
試してみて、あなたに仕える方法を教えてください。貢献ルール、機能強化、テスト、バグ、ファイルの修正、新しいアイデア、または単なるフィードバックなど、より良い改善のアイデアがある場合は、メッセージを教えてください！このように、すべてのレベルのすべての開発者にはやるべきことがあります。