[repo] dompurify の宣言が package.json (^3.4.13) と lockfile (^3.4.14) でずれており npm install のたびに差分が出る

[shinyaoguri]

main (d24b7f9) で npm install を実行すると、何も変更していないのに package-lock.json に差分が出る。

-        "dompurify": "^3.4.14",
+        "dompurify": "^3.4.13",

原因

PR #260 (293c98c, dependabot) の中身が package.json と lockfile で食い違っている:

ファイル	記録されている範囲
packages/editor/package.json:18	^3.4.13
package-lock.json の packages/editor.dependencies	^3.4.14
package-lock.json の node_modules/dompurify.version	3.4.14

PR タイトルは「3.4.12 → 3.4.13」だが、lockfile 側だけ 3.4.14 に進んでいる (dependabot が PR 更新中に上流の新版を拾い、package.json の hunk が追随しなかったと見える)。

影響

• npm ci は通る (3.4.14 は ^3.4.13 を満たす) が、npm install するたびに lockfile が書き換わる。作業ブランチに無関係な lockfile 差分が混入し、git status のノイズと誤コミットの元になる (実際、[verify-cli] proof 由来の language が無検証で stdout に出る (偽の Checks 行を注入できる) #266 の作業中に混入して手で revert した)
• 「lockfile が package.json の宣言を映している」という前提が崩れているので、依存の実態を lockfile から読む作業 (監査・[repo] README の依存表と package.json の突合を freshness.yml に足す (dependabot が package.json だけ更新するため構造的にドリフトする) #269 の突合) が誤読する

対応案

packages/editor/package.json を ^3.4.14 に上げて lockfile と揃える (実際に入っているのは 3.4.14 なので、こちらが実態に合う)。逆向き (lockfile を 3.4.13 へ戻す) は上流の新版をわざわざ捨てることになる。

関連

• [repo] README の依存表と package.json の突合を freshness.yml に足す (dependabot が package.json だけ更新するため構造的にドリフトする) #269 — 「dependabot が package.json だけ更新するため構造的にドリフトする」の逆方向 (lockfile だけ進んだ) の実例。[repo] README の依存表と package.json の突合を freshness.yml に足す (dependabot が package.json だけ更新するため構造的にドリフトする) #269 の突合チェックを freshness に足すなら、package.json ⇄ package-lock.json の範囲一致も同じ仕組みで検出できる
• fix(deps): nanoid の high 脆弱性 (GHSA-2v37-7h3g-55p8) を override で塞ぐ — dependabot の自動更新が失敗し続けている #270 — 同じく dependabot 起因の依存まわり

---

_{🤖 Assisted by Claude Code}