入社して4ヶ月が経ち、会社にも少しずつ慣れてきました。1日目の記事として、Qiita及びQiita:TeamでのCSSの構成について書きます。Railsを採用しています。いうRailsにbundleされているassetビルドツールを使ってSassをCSSにコンパイルしていました。JSのビルドをNode.jsで行っています。CSSでの移行手順はざっと以下の通りです。使ったときよりも約10倍高速です。Qiita:Teamが依存しているbootstrap-sass等の外部のCSSライブラリを全てnpmからインストールします。いうSassのフレームワークを使用していたので、その部分のコードを全て書き換えます。ベンダープリフィックスを付けていたところは、後述するAutoprefixerに任せました。変更し、Sassを1エントリーファイルでコンパイルできるようにディレクトリ構成を見直しました。Sprocketsはassetsファイルのビルドだけでなく、以下のことも行います。2のスクリプトをNode.jsで書くことで、ビルド完了までをNode.jsで完結することができました。Middlewareとして実装されています。担当し、脱Sprocketsをすることができました。PostCSSの導入PostCSSという、CSSのソースコードを入力として受け取り、任意の処理を加えてから出力するツールがあります。Qiita:Teamの開発でも、PostCSSを使ったプリプロセスや最適化、コードのリントを行っています。書いていくので、良かったらこちらを読んでみて下さい。Qiita:Teamでは、新規に追加するコードはSass(node-sass)ではなく、PostCSSのプラグインをいくつか使ってプリプロセスをしています。プリプロセスのために使っているプラグインは以下の5つです。使ったファイルのインライン展開をするプラグインです。postcss-importを使って、これまでのSassでコンパイルしたコードとPostCSSでプリプロセスしたコードをconcatしています。いう@ルールでメディアクエリーのパラメーターに名前を付けるプラグインです。Jr.という人が書いている仕様を元にしたプラグインです。Propertiesという複数のプロパティー宣言に名前を付けるものと、既存のプリプロセッサーにあるようなセレクタのネスト表記をするためのものです。...}僕は、プリプロセッサーとしてPostCSSを使うなら(少しでも)標準化される可能性のある仕様をベースにしたプラグインを使うようにしています。SassやStylus等、既存のプリプロセッサーにロックインされるのを防ぐためですが、PostCSSのプラグインは不安定なものも多く、良いプラグインを嗅ぎ分ける嗅覚と、何かトラブルが起こったときにはコントリビュートする覚悟が必要になります。最適化のためのPostCSSプラグイン次にプリプロセス後のCSSコードに対して後処理(ポストプロセス)、最適化を行うためのプラグインについてです。Qiita:Teamでは以下の3つを使っています。いうサイトのデータを元にベンダープリフィックスを自動で付与するためのプラグインです。ベンダープリフィックス付与ツールとしてだと、前述したCompassよりも約55倍高速です。中から、CSSの変形のみで対応できるバグ修正をおこなうプラグインです。プロパティー宣言の順序を並び替えるプラグインで、最適化のフェーズでpostcss-sortingを使っているのは、gzip時の圧縮率を高める可能性を上げるためです。CSSのminifyをしています。いうCSSのリンターがあります。Properties等を使ったCSSの新しいシンタックスに対してもリントすることができます。Qiita:Teamでは今までscss-lintを使っていましたが、stylelintに乗り換えました。stylelintは指定できるルールの数が約170個と多く、また全てのルールはPostCSSのプラグインとして実装されているため、独自のルールを書くことも可能です。JSのESLintのように、非常にカスタマイズ性の高いCSSリンターです。いう名前で公開しています。Qiita:Teamでの設計手法についてです。概ね僕が自分のブログで書いた通りのルール分割となっているので、以下の記事を参照して下さい。JS系のツールは使っていません。いかがでしたでしょうか。upLoginユーザーは見つかりませんでした。