Jekyll 3 + JekyllAssets + Parcelの環境を作ったけど注意が必要だった

先日の Middleman 4.2.1 + External Pipeline + Parcel 1.12環境を作れた - あーありがち(2018-11-23) に続いて Ruby の静的サイトジェネレータと Parcel を組み合わせる実験。

Middleman の評価については別に話があるんだけど、それは置いておく。

Jekyll には Middleman の External Pipeline のような仕組みは存在せず、各位で頑張って webpack を使う boilerplate が何個もできているような状態だったりする。

Search · jekyll webpack

これはこれで参考になるんだけど、できるだけ生で Webpack を触りたくないということで今回は前回に引き続いて parcel を使ってみることにした。

素材

ディレクトリ構成

前回と同様に

+- bin/
+- assets/     parcelが処理するもの
+- source/     jekyllが処理するもの
    +- assets/ parcelの処理結果かつjekyll-assetsのサーチパス

とした。

npm scriptsとnpm-run-allで処理を制御

Jekyll には External Pipeline のような賢い仕組みは存在しないので、build の際には

  1. parcel
  2. jekyll

の順番でコマンドが実行されるようにしてあげないといけない。

serve の際には npm-run-all で parallel に実行してあげれば両方ともいい具合に watch して rebuild してくれるのでそんなに気にする必要はない。

assets/ 以下を編集 → parcel が処理して source/assets/ に反映 → jekyll が処理して _site/assets/ に出力

が自動的にグルグル回ってくれる。

なぜJekyllAssetsか

サーバに依存しない cache buster のため。

Jekyll 自体には cache busting を支援する仕組みはなく、いろんな組み合わせがあり得る。例えば Web サーバを直接設定できるのであれば、revision を適当に URL に埋め込んで処理するという方法もある。

しかしせっかく静的サイトを生成するのであれば Web サーバには依存したくないというのが正直なところで、例えば S3 + CloudFront で似たようなことをやろうと思うと Lambda 使ってくださいみたいな話になっちゃって、静的サイトでサーバ要らずとはなんだったのか？という気持ちになってしまう。

注意すべきはjekyll-assetsのファイル名の扱い、特にparcel watchと組み合わせた時

parcel にも HTML からまとめて build させるとすべて同じディレクトリにフラットにぶちまけられてしまう問題があったが、jekyll-assets には

assets/ 以下のパスをいい具合に検索する機能

があるおかげで、

同じ名前のファイル名があるとどっちが正なのか分からなくなる

という致命的な問題がある。

どういうことかというと、例えば

assets/js/site.js
       css/site.js

があった場合に

{% asset site.js %}

と書くとどっちの site.js を読み込んでよいのか分からなくなってしまうという問題だ。

上の例だと「そんなことやるわけじゃないじゃん？」と思うかもしれないが、parcel は CSS に対しても HMR 用の JS を吐くので、意図せず同じ名前の JS が生成されてしまうことはあり得るのですよ。

ということで、

parcel + jekyll-assets を使う場合はファイル名のルールをちゃんと整えるべし

と思ったのでした。

ただ、そこさえ考えておけば必要な設定がほとんどないというのはやはり魅力。そこは JekyllAssets も Parcel も優秀だと思う。

例によって成果物

wtnabe/jekyll-v3-example-with-jekyll-asset-and-parcel

こんな感じ。

More