俺のフロントエンド依存管理ポリシー20241120

• ポリシー: この世界では常に最新版を使うという気持ちで生きていく
  • Node.js は枯れるという概念がなく、常に古いことはリスク という認識。LTS も短め(3年)
  • 古いAPIのドキュメントは常に消失する
  • モダンなツールは、モダンな前提を要求する
  • ~2020: CJS/ESM 関連で断絶がある(jestが動かなくなりつつある)
  • ~2019: パフォーマンス意識が低い時代の実装が多い
  • ~2015: Node.js のみでしか動かないものが多い。peerDeps の意識が低い
  • この辺で目視でポチポチする
    • npm: npm-check-updates - npm
    • yarn upgrade-iteractive
    • pnpm upgrade -i
• サーバーランタイムには安定を、ツールチェインにはパフォーマンスを
  • サーバーランタイム(Node.js)
    • Node 本体は Stable LTS か、一つ前の Stable LTS
    • Next/Nuxt は最新についていかないと篩い落とされる
  • ビルドツールチェイン(ローカルNode.js)
    • 概念的に同じアセットを出力するなら、依存は全部あげて良い
    • マイナーバージョンでは、機械的に全部更新する
  • テストツール(vitest)
    • 常に最新。バージョンを上げて動くこと自体がテストみたいなもの。
    • デフォルト挙動やターゲットの指定が変わってすっぽ抜けてないかだけ注意する
• dependencies/devDependencies の依存管理
  • 本来は Node/Expressのサーバー等でテストツールを含まない仕組み。ちゃんと管理しないと、Docker イメージが肥大化する
  • 現代だと区別ができない 誰も真面目に管理してなかったが、Next系はサーバーサイドもビルドするのでより不透明になった
  • 本番のバイナリ依存ライブラリだけが、dependencies になる
  • 最終ランタイムでは npm install -p か、 node_modules が全くないのが望ましい
• Semantic Versioning との向き合い方
  • バージョン名は参考値。俺達は(世界は)雰囲気で Semver をやっている
  • マーケティング用のメジャーバージョンで、従っていないプロジェクトも多い(TypeScript)
  • 怪しいバージョニングをする作者がいたら、人読みする
• 常に機械的に全部更新する
  • 上げないことがリスク。上げないと、次が上げられない。気付いたら他のツールと一緒にデッドロックしている
  • 安心のためにテストカバレッジを可能な限り上げておく
    -vitest --run --coverage で (66%以上) ほしい
• 実行環境: Node/Deno/Bun/Workerd
  • サーバーには枯れてる Node
  • Deno は書き捨てのスクリプトに便利(依存の事前 install が不要で実行時解決)
    • AI 関連スクリプトは Deno で全部書いてる。
  • Bun 個人的にまだ信用してない。速度面のメリットも自分は感じたことがない
  • Workerd: Cloudflare の実行環境。バンドル前提でサブセットのESM水準だけ信じて動かす
• フロントエンドバンドラの選定
  • 前提: フレームワークの前提に従う (Next => Turbopack)
  • Vite: 第一選択肢。今後は全部これに実装される
  • Webpack: 存在がリスクになっている。sokra先生がTurbopackにいってしまったのでメンテが…
  • Turbopack: Next 以外でロクにテストしてない。Webpack のサブセットなら
  • Rspack: 手元で動かしたら速かった。Webpackのサブセットなら
  • Rollup: ライブラリ作者向け。自由度は高いが、
  • Rolldown: 意識高い人向け。次期 Vite 基盤
• SSR フレームワークの選定
  • React 系
    • Next/Remix 迷うぐらいなら Next
    • Next(Turbopack) の独自性に難を感じるなら Remix(Vite)
  • Vue 系
    • Nuxt (Vite)
  • Svelte 系
    • Sveltekit(Vite)
  • Web制作
    • Astro(Vite) でアイランドアーキテクチャしておけば潰しが効く
• テストランナー
  • 現状 vitest 一択
  • jest は esm 対応がよくなく、高速に負債化している
  • mocha スレッド制御がない
• Storybook
  • 昔から設計が悪く、強烈な負債発生源(webpack強依存)
  • 本当に運用できてるなら維持してもいいが、そうでないなら離脱も検討する
• Linter/Formatter
  • eslint:
    • 遅い。年季が入りすぎて動かすのすらしんどいが、ここにしかないものがある
    • typescript-eslint 関連の依存が重い
    • no-floating-promises はまだ eslint ぐらいしかない
    • react hooks 系の Linter も eslint が多め
    • 依存更新時に eslint がブロッカーになるなら、他に移行しつつ捨てていいと思う
  • oxc: 筋が良さそうだが、まだ枯れてない。
  • biome: 基本的に無設定でそこそこ動くので雑に eslint を置きかえたいなら。速い。エコシステム的には oxc 系のが勢いがある
  • dlint: deno なら使う。それ以外は優先度上がりづらい
  • prettier: biome/oxc/dlint ならフォーマッタを内蔵してるので、そちらを優先して不作用でもいい。セミコロンはつけたほうがいい。
• E2E
  • 前提として、本当に必要性を理解するまで手を出さない
  • Playwright | Puppeteer の二択。(vitest/browesrまだ早い)
  • playwirght/test がリトライ制御等を含めて良く出来ている