先日参加したCSS Nite LP54 「Coder's High 2017」で行われたアンケートで、思ったよりstylelintの使用率が低そうだったので、実務で使っている感想を書いてみました。
この記事に書いてないこと
- stylelintについての説明
- stylelintの導入方法
この記事に書いてあること
- postcss.config.jsの設定例
- .stylelintrcの設定例
- stylelintを使い始めて良かったこと
前提
PostCSSとstylelintを組み合わせて使っています（Sassは使っていません）。
設定ファイルは以下のような感じです。
package.json
デプロイ時のみ"build:css"を実行します。
{
"scripts": {
"watch:css": "onchange -w -d 1000 'css/src/**/*.css' -- npm run compile:css",
"compile:css": "NODE_ENV=development node ./node_modules/postcss-cli/bin/postcss 'css/src/*.css' --config postcss.config.js -m -d css/dist/",
"build:css": "NODE_ENV=production node ./node_modules/postcss-cli/bin/postcss 'css/src/*.css' --config postcss.config.js -d css/dist/",
}
}
postcss.config.js
postcss-nestedはほとんど使っていません。
実際にCSSコーディングに大きく影響しているのはpostcss-import、postcss-custom-propertiesぐらいです。
package.jsonのbuild:cssで実行された場合は、stylelint・mapファイルの出力を無効化して、cssnanoで圧縮するようにしています。プロジェクトによっては、firstview.cssをインライン化する場合もあります（インライン化自体はgulp-file-includeで行っています。より良い方法があれば教えていただけると助かります）。
// ctx.env = NODE_ENV
module.exports = (ctx) => ({
map: ctx.env === 'development' ? {} : false,
plugins: {
// stylelint -> postcss-importでないとstylelintのオプションが反映されなかったのでこの順番にしています
// postcss-importを他のpostcssプラグインの前に読み込まないとエラーになった
'stylelint': ctx.env === 'development' ? {} : false,
'postcss-import': ctx.env === 'development' ? {
plugins: [
require("stylelint")({
ignoreFiles: 'css/src/*.css' // 上のstylelintと重複するため無視
})
]
} : {},
'postcss-nested': {},
'postcss-custom-properties': {},
'postcss-reporter': {
clearReportedMessages: true
},
'css-mqpacker': {},
'autoprefixer': { browsers: 'IE 11, last 2 versions' },
'cssnano': ctx.env === 'development' ? false : {}
}
});
.stylelintrc
stylelint-config-primerを使っていますが特に理由はありません。他のパッケージは使ったことないので、使っている人の感想も聞いてみたいです。
rulesがやたらと並んでいるのは、"> 1%" にOperaが含まれていて、stylelintで指摘されるたびに無効化しているからです。次に設定ファイルを作る時は、対象ブラウザを変えたほうが良さそうですね。
{
"extends": "stylelint-config-primer",
"ignoreFiles": [
"./css/src/foundation/normalize.css",
"./css/src/object/utility/util.css",
"./css/src/object/utility/emma-util.css"
],
"rules": {
"plugin/no-unsupported-browser-features": [true, {
"browsers": ["> 1%", "IE 11", "Last 2 versions"],
"ignore": [
"flexbox",
"border-radius",
"transforms2d",
"css-appearance",
"calc",
"user-select-none",
"css-transitions",
"viewport-units",
"background-img-opts",
"css-gradients",
"css3-cursors",
"css-resize",
"css-boxshadow",
"css-fixed",
"pointer-events",
"multicolumn",
"outline",
"css-featurequeries",
"font-feature"
]
}]
}
}
本題
タイトルにもある通り、stylelintを導入してだいたい3ヶ月くらい経過しています。いろいろとメリットはありましたが、その中でも特に大きかったのは以下２つです。
コーディング速度が向上する
stylelintルールのひとつに、properties-orderというものがあります。widthの前にheightの指定が書かれている、などプロパティ同士の順番を指摘してくれるルールです。上記の設定ファイルの場合、だいたい以下のような順番になります。
- position系
- position -> top, right, bottom, left -> z-index
- position -> top, right, bottom, left -> z-index
- ボックスモデル系
- display -> width, height -> padding, margin
- フォント系
- font-size, font-weight, line-height -> color -> text-align
- 背景
- background -> background-size, background-position
- ボーダー系
- border -> border-radius
基本的にこの順番でプロパティを指定していくことになる（順番が違っているとstylelintで注意される）のでスムーズなコーディングができます。まずは、配置を決めて余白を調整し大枠を整え、その後でフォント・ボーダーなどの細かい部分を調整という流れになるため、大きく崩れて手戻りする、ということがかなり少なくなります。
CSSは記述量が多くなる場合もあり、少しの手戻りでも、繰り返し発生することで大きな時間のロスにつながります。このロスが少なくなり、CSSを書くことよりも良いデザインを実装することに時間を割けるようになったので、これまでより多くの見直しを重ねることができました。
リファクタリングする癖がつく
これは個人の開発スタイルによりますが、私の場合、２画面のうち片方でエディタを開き、もう片方でコンソールを開き、スタイルを変更するたびにstylelintの結果を画面に流すようにしています。指摘が少ないうちは気にならずにコーディングを進めていけますが、進めるうちにかなり溜まってくるので、どうしても気になって一気に解消する、というのを繰り返しています。だいたい３コミットに１回ぐらいはstylelintの対応を一気にしています。
CSSは簡単にプロパティが追加でき、勢いでコーディングを進めることも可能ですし、詳細度での上書きや!importantなどで、過去に書いたコードを修正しなくてもなんとかなってしまう場合が多いです（自分だけかもしれませんが）。
こまめにリファクタリングすることで、無駄なコードを減らすことができ、気持ち的にもすっきりした状態でコーディングを再開することができるようになりました。これまではコード量が多くなるとCSSを書くのに飽きてきていましたが、現在ではCSSへのモチベーションを維持できているような気がしています。
まとめ
導入が少し面倒で、最初は山のように指摘が来るため慣れるまでに1ヶ月ぐらいはかかりましたが、個人的にはDX（デベロッパーエクスペリエンス）がかなり向上したので、試しにでもいいので使う人が増えるといいなー、と思っています。
stylelintで快適なCSSライフを送りましょう！