139
125

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Sassを捨ててPostCSSに移行したのでそのときの工程メモ

Last updated at Posted at 2016-03-07

CSSはずっとSassを使っていて、gulp-sassでコンパイルする感じの僕でしたがPostCSSに移行してみたのでそのときの工程をメモとして残しておきます。

PostCSSとは何か

なぜSassからPostCSSに移行したのか

むしゃくしゃしてやった。

ほんとは

ただ単にSassを使っているということに飽きたってのが1点。
あとはSassの機能において僕はmixinとかextendとか正直必要ないなって考えていて、変数であるとかネストであるとかimportであるとか(CSSのimportじゃない方の)が使えればそれで良いってのがあって、そうなるとPostCSSの必要な機能だけ読み込んで使うっていうスタンスは良いなっていうのが2点目。
あと結局Sass使ってそのあとにautoprefixerとminifyは確実にやるのでそこでSass以外のツールでCSSのことをあれこれしちゃってるのでそこも含めて全部一括管理できれば良いなあっていうのが3点目。
そんな感じです。
上記の理由なので今回PostCSSプラグインをまとめたパッケージであるcssnextは使用しません。

※なんでmixinとかextendとかいらないかっていうと僕はマルチクラスの設計が好きだからです。CSSをすっきりさせてhtml側で付与するクラスを増やす方がわかりやすいと感じるからです(個人の趣向です)。

※CSS ModulesとかCSS in JSとかを使うのはどうなのかっていう部分はまだまだ僕自身がこれらに対しての不満があったりReactとか関係なく今回はやりたいってのがあったので触れないです。

工程

現在gulp-sassを使ってCSSを生成しているプロジェクトをPostCSSに移し替えるという前提です。あ、ちなみにscssです。
上にあげたようにSassの機能としては変数とネストとimportしか使っていないので、そこを代替する。あとはautoprefixerとminifyの役割ももたせたいのでそこも担うようにする。
CSS設計はFLOCSSを使っているのでそこは崩さないように。ていうかソースコードは既存のままで動くようにする。

追記:ごめんなさい。既存のままでと言いつつ若干変えました。後ろの方で書いてます。

※僕はextendやらmixinやらいらないので入れてないけれどプラグインたくさんあるのでそこの機能も欲しかったら入れられるので欲しい人はぐぐってください。

あとは最近の僕は処理をnpmタスクとしてまとめたい派なのでnpm runの形式で動かせるようにする。

以下の順番です。

  1. PostCSSを使えるようにする為にpostcss-cliをインストール
  2. 必要な機能を持ったプラグインをインストール
  3. PostCSSの設定ファイルを作成
  4. npm run形式で動かす

そんな感じで進めます。

1.PostCSSを使えるようにする為にpostcss-cliをインストール

npmでインストールします。

npm install --save-dev postcss-cli

2. 必要な機能を持ったプラグインをインストール

今回僕がほしいプラグインは以下のものです。

  • postcss-import(ファイルのインポート)
  • postcss-simple-vars(変数)
  • postcss-nested(ネスト)
  • cssnano(minify)
  • autoprefixer(ベンダープレフィックス自動付与)

全てインストールします。

npm install --save-dev postcss-import postcss-simple-vars postcss-nested cssnano autoprefixer

3. PostCSSの設定ファイルを作成

package.json等が置いてあるプロジェクトのルートディレクトリに.postcssrc.jsonを置きます。今回は中身はこんな感じ

{
  "use": [
    "postcss-import",
    "postcss-simple-vars",
    "postcss-nested",
    "autoprefixer",
    "cssnano"
  ],
  "input": "@エントリーポイントのパス",
  "output": "@吐き出すパス",
  "autoprefixer": {
    "browsers": "last 2 versions"
  }
}

4. npm run形式で動かす

.postcssrc.jsonの準備ができたらnpm run形式で動かすためにpackage.jsonにタスクを設定します。
以下はpackage.jsonのscriptsの部分だけ抜粋しています。

{
  "scripts": {
    "build-css": "postcss -c ./.postcssrc.json",
    "watch-css": "postcss -c ./.postcssrc.json -w --map"
  }
}

これでbuild-cssとwatch-cssのタスクを作ることができました。

この状態で以下を叩くと現在Sassで記述しているものをコンパイルすることができます。

npm run build-css

と、ここで重大な注意点なのですが…。
ソースコードを変えずに動かすと言いましたが、今回のプロジェクトはscssを使っていて全てのファイルの拡張子がscssだったのですがこのままだとうまく動かなかったり、importされるファイルのファイル名の先頭に_を入れるようにしてたのですがこの部分もうまく動かない原因になったりってのがあったので…

全てのscssファイルの先頭の_を削除して拡張子をscssからcssに変えるっていう作業をしちゃいました。

前提覆してしまい申し訳御座いませんでした。
心の底から反省しております。

まあそんなわけでファイル名を一括で変えるのは色々頑張ったらどんだけファイル数多かろうが苦ではないのでまあよしとする。

ちなみにnpmタスクのwatch-cssの方は、-wオプションをつけることでwatch機能がついていて、--mapオプションをつけることでsoucemap機能がつきますので開発時はこちらを使います。

まとめ

こんな感じで既存のSassからソースコードを変えずにファイル名をちょい変えてPostCSSに移行することができました。
実際どっちが良いのかって言ったらどっちでも良くて好みでしかないかなって感じなのですが僕の好みとしてはミニマムに使えそうなPostCSSを選ぶかなって感じです。

ほんとにここ最近は僕は薄い実装っていうのが好きなので、必要最低限のことをしてるものの中から必要なものだけを選んで使うっていうのが正義だなってのが僕の意見です。フルスタックはちょっと敬遠している僕です。こちらからは以上です。

139
125
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
139
125

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?