GatsbyからAstroに移行しました

  • タグ:#Astro#雑記

    • 題の通りです

    正直記事タイトル以上のことはありません。 サイト生成環境をGatsbyからAstroに移行しました。

    Astro
    Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.
    astro.build

    普通はこれを機にUIやらなんやら変えるんでしょうけど、 ほぼベタ移植です。それ以上でもそれ以下でもない。

    …これで終わるのはなんなので、実際に移行して感じたことでもまとめてみようと思います。

    良かった点

    HDDからでもキビキビ動作

    使ってるSSDが全て容量カツカツなので、かなり助かりました。

    Win11 23H2以前はGatsbyでもそれなりでしたが、今は何をどうしてもHDDでは信じられないくらい遅い。 以前はPC起動時の初回実行は一分ほど、再実行は30秒ほどで起動できていたのですが、 再実行でも数分待ちという大幅下方修正を食らっています。

    似たような状況に陥った方は少数いるものの未解決らしく、 私も仕方ないのでSSDから使っていました。

    CSSを1ファイルからURLによって切り替え可能

    Gatsbyの時はURLでblog以下とそれ以外でのスタイル変更を、タグほぼ全てをクラス名で管理するという力業で実装していました。 当時は知識がほぼゼロに等しかったのもあるのですが、力技のほうが労力的にマシそうでこうなりました。

    Astroではviteによる?urlでパスだけ取得し、html側でlinkを書いて実装。

    BaseHead.astro
    ---
    import globalCss from "../styles/global.css?url";
    import globalBlogCss from "../styles/global_blog.css?url";
    

    const { pathname } = Astro.url;
    

    const cssHref = pathname.startsWith("/blog")
      ? globalBlogCss
      : globalCss;
    ---
    

    <head>
      <link rel="stylesheet" href={cssHref} />
    </head>

    双方のテンプレでインポートし、無事ファイル単位での切り替えに成功。

    GraphQLがない

    いやぁクッソ楽でしたわ

    Astroで似たような内容を再現したらコードがとても短い。Gatsbyはちょっと追加するとなったら、gatsby-node.jsで細々長々書かなきゃならなかったのにAstroは短い。最高。

    当時より多少スクリプトの理解があるとはいえ、初動でのとっつきやすさには明確に差があると感じます。 まあ後で痛い目見たんですけどね…

    URLは基本的にpagesのフォルダ階層準拠

    個人的には嬉しかったのですが、人によっては不満があるかもしれません。

    Gatsbyなどのように記事のURLをサイトのルート直下にしたい場合、/src/pages/[...slug].astroに記事生成スクリプトを配置するかありません。 SSRモードだのサーバー設定だのでURLを書き換えられるそうですが、個人サイトでやることではない気がします。

    個人がそのようなルールで作成したいなら、Astro以外を使ったほうがよさそうです。

    困った点

    MD記法での相対リンク指定が画像以外非対応

    Astroはmdファイルの記法で画像以外を相対リンクしても、ビルド時にファイルパスを参照できません。 Gatsbyは拡張インストールでMDから相対リンクで拾える、つまりGraphQLの扱い次第でどうにでもできますが、Astroにそのような拡張はありません。

    公式によれば画像以外はPublicフォルダに設置しろとのことですが、 ソースファイルは記事と同階層を維持したいのと、GatsbyのようなURLのハッシュ化が目的だったので、その方法は取れませんでした。

    最終的に超環境特化Integrationsをなんとか作成して解決。 作業時間の大半はここが締めました。

    フロントマターに書いた相対リンクのURL化で詰む

    Astroが動いた時点でフロントマターに介入する術がないようで、 専用DB実装くらいしか手がないようです。

    仕方なく記事IDとフロントマターからURL生成するスクリプトを別途作成し、 記事テンプレートから呼び出す形で妥協。 今のところ1つしか扱わないので…

    ビルドの度にdistフォルダ初期化

    根幹挙動などどうしようもないので、ビルド後に公開用フォルダに差分コピーするコードを追加。

    —forceで初期化すれば毎回ビルドに含めるようにはなりますが、当サイトは画像以外のファイルだけで普通に3桁はあります。単純にGatsbyでいうcleanに相当するコマンドなので、ビルドの度にそれらファイル全てのコピーが発生します。

    ビルドの度に全コピーされるよりはマシでしょう。

    node_module/astro/dist以下がたまにファイルロックされる

    キ　レ　そ　う

    dev実行時間が長いと発生しやすいような気がします。 こまめな停止大事。

    こうなるとネットにあるファイルロック関係の解決策は一切効果がなく（再起動すら無力）、セーフモードにしないと該当フォルダを削除できませんでした。 その都度npm createからやり直してます。

    解決策は「仮想でいいからLinux環境で動かせ」だそうです。

    あとがき

    なんか不満多めに見えるけど満足はしてます。

    それくらいメリットが強い。 GraphQL（相対リンク）関連もギリ楽が勝つ。ビルド時のファイル削除は回避策講じたんで… 今はAstroで十分と言われることが多いようですが、実際に試してそれは良く分かりました。

    だがファイルロック、てめーはだめだ

    …まあこの手のことする人は大体Linux環境を持っていると思うので、あまり問題ないのでしょう。 もうそんなに長時間devで動かすことはないだろうから、多分何とかなる。

    一番終わってたBGM個別ページには、オーディオビジュアライザー設置。

    01

    ファイル周り無駄に苦労したのはほぼこれ作った所為です。

    若干サイトから浮いてる気がするし、ブログも安定のほぼ初期スキンなのでどうにかしたいんですが、 それはまあそのうち…

    使ったコマンド覚書

    npm create astro@latest
    npx astro add astro-expressive-code
    npm install remark-code-titles axios cheerio @fontsource/noto-sans-jp @fontsource/noto-serif-jp serve @expressive-code/plugin-line-numbers