今までビルド毎に全ての記事を再生成していたのに対して更新があった差分だけビルドする機能で現在βテスト中の機能だ。
前回の記事ではエラーが出ていたため利用できなかった。
以前は次のエラーが出ていてインクリメンタルビルドができなかった。
WebpackError: TypeError: Cannot read property 'childImageSharp' of null
これは画像のパスが解決できていないということだが、どうやらMarkdown
から参照している画像がstatic
にあると発生する模様。
もしstatic
に直接画像を保存してMarkdown
から参照している場合は、全ての画像ファイルをBLOG記事とおなじsrc/pages
内部に変更すること。
実際に私の環境ではmd
ファイルが保存されているフォルダの中にimg
フォルダを作ったので実際はsrc/pages/blog/img
となった。
この変更によりインクリメンタルビルドが正しく動作するようになった。
もしまたエラーが再発した場合は次のコマンドでキャッシュを削除し全体ビルドをやり直してやれば治る可能性がある。
gatsby clean
Netlify
側でインクリメンタルビルドするには前回は失敗したが、基本的に前回の記事と同様の作業をしてもらえば正常に動作するはずだ。
ぜひとも試してみて欲しい。
コンテンツメインは以上でここからはエラー原因を探し当てた方法であるので興味があれば読んで貰えればと思う。
そもそもHTML
のパスについて特別詳しくない私だがパスにスラッシュがないと画像が読めないという動きを調査していた。
./img/画像
やimg/画像
だとstatic
の画像がうまく読めない。/img/画像
でなければならない。ここに疑問があった。
はじめはgatsby-image
のバグだろうと思っていたのだが何気にHTML
上では一切パスの変換が行われておらず画像が表示されるかどうかはブラウザ側のパスの解釈によるものだと分かった。
そもそも/img/画像
はultra-noob.com/img/画像
を指し、./img/画像
はultra-noob.com/blog/記事名/img/
にアクセスしている。これはこれで勉強になった。
まずはこの動作の違いに気づいたのでなにかオカシイと思った。
static
フォルダの画像は変換後にコピーされるものstatic
に入れたデータはたしかにそのままURLで公開されるが、BLOG記事の画像に関してはsrc(開発専用フォルダ)
からサイズやプレースホルダ等の処理されて変換されたものがstatic
にコピーされて自動的にパスが付与される、というのが本来の仕組みであることに気づいた。
だとすると、上の画像URLが記述したそのままになっているのはオカシイ。
本来ビルド時に変換されなければならないのだ。
src
の中に必要つまりsrc
に画像を入れておいてビルド時に処理をさせて自動でstatic
に保存されるわけだ。
static
に保存した画像を直接Markdown
から指定していたのが間違いだった。
というわけで、これが記事を更新したときに画像のプラグインで発生するエラーの原因だった。
またBLOG記事内の画像のプレースホルダ(ロード中の仮画像)が正しく表示されない不具合も解消された。