構文チェック系の続きです。前回はESLintでJSコードの構文チェックを事始めました。今回はStyleLintでCSSコードの構文チェックを事始めます。それでは行きまっしょい！
【目次】
- StyleLintのインストール
- StyleLintの設定方法はいくつかありそう
- package.jsonに設定を追記
- テスト用のcssファイルを作成
- 構文チェック実行
- 修正、再実行
- 再修正、再々実行
- 最後に
※参考：【JS】ESLintで構文チェックを事始める - クモのようにコツコツと
Web開発環境まとめ qiita.com
StyleLintのインストール
CSS系の構文チェックについて調べるとStyleLintが一番定番のようなのでどんなものか体験する。
まず、Node.jsとnpmは既に入っている前提（ターミナルで下記を叩くとバージョン番号が出る）
node -v npm -v
StyleLintを入れるフォルダを作る。今回は「stylelint_test」とした。
cdコマンドでstylelint_testフォルダに移動。
cd （フォルダのパス）/stylelint_test
package.jsonの作成
npm init -y
ローカルにStyleLintをインストールする。
npm i -D stylelint
package.jsonにStyleLintの記述がでた！
"devDependencies": { "stylelint": "^13.0.0" }
ここまでは他のツールと大体同じ作業。
StyleLintの設定方法はいくつかありそう
StyleLintの設定を追加する。ここが調べるといくつか方法があって戸惑ったが、こちらの記事の方法が一番シンプルに感じた。
※参考：lint, prettier導入編（mac） - Qiita
まずStyleLintの標準のルールセットをインストールする。「stylelint-config-standard」という。
npm i -D stylelint-config-standard
package.jsonに追記された！
"devDependencies": { "stylelint": "^13.0.0", "stylelint-config-standard": "^19.0.0" },
次にこれをStyleLint本体に適用する必要があるのだがこれがいくつか方法があるようだった。
- .stylelintrcに書くとか
- .stylelintrc.jsonに書く
- stylelint.config.jsに書く
- package.jsonに書く（stylelintキー）
これらの隠しファイルもインストール時に自動的に作られるんだか自作するんだか、自分のコマンド系の知識不足でイマイチよくわからない。確実に言えるのは自動的にはファイルは作られていないようだ、ということ。
先ほどの参考記事ではpackage.jsonに追記する方法が紹介されており、一番シンプルな作業なので自分もこれに従ってみる。
package.jsonに設定を追記
ということでpackage.jsonに追記する。
"devDependencies": { "stylelint": "^13.0.0", "stylelint-config-standard": "^19.0.0" }, "stylelint": { "extends": "stylelint-config-standard" }
stylelintキーを作る。値は連想配列のネスト（入れ子）- ネストの連想配列の中に
extendsキーを作る extendsキーの値はstylelint-config-standardを入れる
ひとまずはこの1行のみで。これで先ほどインストールしたstylelint-config-standardの標準ルールが適用される。
なお、固有のルールを追加したい場合はrulesキーを追加するといいみたい。
"devDependencies": { "stylelint": "^13.0.0", "stylelint-config-standard": "^19.0.0" }, "stylelint": { "extends": "stylelint-config-primer", "rules": { "hoge": "fuga", "hoge": "fuga", "hoge": "fuga" } }
ルールの例、自分も今後色々見て行きたく。
※参考：stylelintを使い始めたので設定例など (2016年9月更新) - yuw27b’s blog
※参考：stylelintの導入方法と各ルール解説 - Qiita
※参考：stylelintのルール簡単説明（v5.4.0） · GitHub
よく見ると重複チェックとかプロパティの記述順（アルファベット順とか）などもやれるっぽい！これはすごい！
テスト用のcssファイルを作成
「stylelint_test」フォルダの直下にテスト用のcssファイルを作る。「test.css」とした。
h1 { color: red fonto-weight: bold; }
colorプロパティの行末のセミコロンを抜いてみたfont-weightプロパティをfonto-weightと打ってみたw
さあ、StyleLintの構文チェックではどういう結果が出るか。
構文チェック実行
いよいよ構文チェックの実行です！こんなコマンド
npx stylelint パス/ファイル名
今回は直下の「test.css」なのでこうなる。
npx stylelint test.css
実行！
結果は…お。
test.css 2:12 ✖ Missed semicolon CssSyntaxError
- 2行目の12文字目：欠落したセミコロンCssSyntaxError
SyntaxErrorは構文エラーね。
修正、再実行
言われた通りに直してみる。
h1 { color: red; fonto-weight: bold; }
再実行！
npx stylelint test.css
結果、おお！
test.css 2:5 ✖ Expected indentation of 2 spaces indentation 3:5 ✖ Unexpected unknown property "fonto-weight" property-no-unknown 3:5 ✖ Expected indentation of 2 spaces indentation 4:1 ✖ Unexpected missing end-of-source newline no-missing-end-of-source-newline
- 2行目の5文字目：2つのスペースのインデントが予想されるインデント
- 3行目の5文字目：予期しない不明なプロパティ "fonto-weight"
- 3行目の5文字目：2スペースのインデントのインデントが予想される
- 4行目の1文字目：予期しないソース終了改行の欠落
fonto-weightはちゃんと見つけてくれた。
あとインデントはタブを打ったらエディタの設定でスペース４つに変換されたようだが、StyleLintではスペース2つが標準ルールっぽい。
再修正、再々実行
再度修正する。
h1 { color: red; font-weight: bold; }
再再実行！
npx stylelint test.css
結果
test.css 4:1 ✖ Unexpected missing end-of-source newline no-missing-end-of-source-newline
むむむ。。よくわかんなくてスルーしてた最後のやつが残ったぞ… 「予期しないソース終了改行の欠落」ってなんだ？改行を入れればいいのかな？
調べると「No newline at end of file」というのはgitコマンドでも出るエラーらしく、やはり一番最後に改行を入れなさいよ、という意味らしい。
※参考：No newline at end of file というエラー | ハックノート
なんか、自分はこれまで最後に余計な改行を見つけるとわざわざ消していたような気がするのだが、本当は改行を１つは入れることが推奨されるのかな？知らないで続きのコードを書くと繋がっちゃうからかな？
改行を入れてみる。
h1 { color: red; font-weight: bold; }
再度実行すると…
npx stylelint test.css
…シーン。返事がない。ただのしかばねのようだ。
そう、Lintの場合返事がないのは良い知らせ。何も問題がないということだ（ESLintもそうだった）
最後に
ということでCSSの構文チェックStyleLintを初体験しました。CSSはJSに比べると複雑な構成ではないけれど、記述量が増えてくると重複チェックや順番変更など色々と助けてもらえそう！以前紹介したコード整形ツールPrettierとの連携方法もあるようです。
この流れで次はHTMLの構文チェックもトライしたく思います！HTMLのLintツールを調べるとどうもHTMLLintよりHTMLHintの方が定番っぽいのでそちらを触る予定。それではまた！
Web開発環境まとめ qiita.com
