postcss

We fresh-cloned the top 100 npm packages. The biggest problem we found was in our own tool. TL;DR We ran CloneProof, a static "will a fresh clone of this repository install and run?" checker, on the GitHub repositories of the 100 npm packages with the most dependents. We wrote down the method and the judging rules publicly before running a single check. - 9 of the 10 build-failing findings in the pre-registered run were false, all from one check: CloneProof mistook README usage examples ("add this script to your package.json, then run it") for instructions about the repository itself. Only 1 of the 6 repositories it would have failed in CI deserved it. - After fixing what this study exposed, every build-failing finding is real. On the same 100 repositories, CloneProof v0.2.4 fails 3, and all 3 deserve it. 60 of its 63 warnings are correct, up from 56 of 73. - 12 of 100 repositories have at least one real setup finding. Six run a real browser as part of npm test. Five have tests that the root npm test cannot run: three workspace roots, husky's shell suite, and dart-sass's Dart suite. One commits a stale npm lockfile next to the pnpm lockfile it actually uses. - 7 of 100 repositories could not be checked at all because they exceed CloneProof's clone safety limits: TypeScript, DefinitelyTyped, webpack, Babel, Rollup, and jsdom hit the 10,000-file or 25 MiB per-file limits, and Inquirer.js has 4.6 GiB of history. The short version: these projects are in very good shape, and the most useful thing this study found was a set of bugs in CloneProof, now fixed. Why fresh clones matter CI runs on a warm, configured machine; a new contributor, reviewer, or agent starts from git clone and the README. The gaps between the two are small and annoying: a lockfile npm ci rejects, a test command that quietly needs a browser, an undocumented environment variable. CloneProof looks for them without running any of the repository's code. Method Population. We walked the npm packages with the most dependent packages, from the ecosyste.ms registry API (fetched 2026-10-30), and mapped each to its GitHub repository. Archived repositories (17 packages, including node-sass, tslint, and cross-env) were skipped. Packages that share a repository, such as 15 Babel packages and 7 @types/* packages, count once. Reaching 100 unique repositories took the top 153 packages. Scope. CloneProof checks the repository root, the way a contributor sees it after git clone. For monorepos, the published package lives in a sub-folder, so results describe "setting up this repository", not "installing this package". The check is static: one isolated shallow clone, no install, no repository code executed. Pre-registration. The selection procedure, the sample with expected findings, the procedure, and the judging rules were committed and pushed before any check ran. The judging rules are unchanged from an earlier random-sample run. Judging. Every warning and failure was judged by reading the repository at the checked commit: - real: true, and it matters to someone setting up this repository root; - policy: true, but a choice a reasonable maintainer makes on purpose (for example, a library that does not commit a lockfile); - false: wrong. Disclosure. All judgments were made by an AI assistant (Claude), which also helped build and fix CloneProof, and were not blind to the tool's output. Each has a one-line reason with file and line references, so anyone can re-judge. Ambiguous rules were interpreted once, in writing, and applied everywhere. Results The pre-registered run used CloneProof v0.2.0. We then fixed the bugs it exposed (see [What CloneProof got wrong](#what-cloneproof-got-wrong)) and re-ran the same 100 repositories with the same judging rules (four had new commits by then; their findings did not change). Both runs are in the table: | | v0.2.0 (pre-registered) | v0.2.4 (after fixes) | |---|---:|---:| | Passed | 31 | 37 | | Passed with warnings | 56 | 53 | | Failed (exit 1, would fail a CI gate) | 6 | 3 | | Blocked by safety limits (exit 2) | 7 | 7 | | Blocking findings: real / policy / false | 1 / 0 / 9 | 3 / 0 / 0 | | Warnings: real / policy / false | 10 / 46 / 17 | 10 / 50 / 3 | !Stacked bars of every finding judged real, policy, or false. Blocking findings: v0.2.0 had 1 real and 9 false; v0.2.4 has 3 real. Warnings: v0.2.0 had 10 real, 46 policy, 17 false; v0.2.4 has 10 real, 50 policy, 3 false. What was real !Repositories with each kind of real setup finding: npm test starts a real browser, 6; tests the root npm test cannot run, 5; stale npm lockfile next to the pnpm one, 1. Tests that need a browser (6 repositories). In chai, axios, vuejs/core, karma, debug, and karma-chrome-launcher, npm test starts a real browser through Playwright, Karma, or web-test-runner. That is a good, deliberate choice, but a fresh machine or minimal container needs a browser installed first. For example: - axios: npm test runs vitest run (package.json:122-123), and the Vitest config includes browser projects with browser.enabled: true (vitest.config.js:16-41). - vuejs/core: npm test runs vitest (package.json:19), which includes an e2e-browser project using Playwright Chromium (vitest.config.ts:104-116). - chai: npm test ends with test-chrome, which runs web-test-runner --playwright (package.json:39-41). Workspace roots without a root test script (3 repositories). tslib, rollup/plugins, and rxjs have test suites, but npm test at the root does not run them. For example, tslib keeps its tests in test/ with a runTests.js driver, and the root package.json defines no scripts. Test suites npm test cannot run (2 repositories, found after a fix). husky tests itself with shell scripts and dart-sass with Dart, and neither root package.json has a test script. v0.2.0 looked only for JavaScript tests and wrongly said both had none. For dart-sass, a Dart project whose package.json serves only its JavaScript tooling, the failure is correct by our rules but may feel like noise to its maintainers. A stale lockfile (1 repository). less/less.js uses pnpm (packageManager, postinstall: npx only-allow pnpm, pnpm-lock.yaml), but it also still commits a package-lock.json that lacks three root devDependencies declared at package.json:33-36, so npm ci refuses to install. pnpm users never notice; anyone whose tooling sees package-lock.json and reaches for npm does. What was policy, not breakage The most common finding by far was no committed lockfile: 29 repositories, all of them libraries published to npm under the same name (eslint, express, chalk, debug, semver, and others). Many library maintainers deliberately leave lockfiles out so their tests run against the dependency ranges users actually get. It is a reproducibility trade-off, not a mistake, and we count it as policy. So are optional switches such as PRETTIER_DEBUG or HUSKY=0 that environment warnings point at: true, but nobody needs to set them. Of the 6 repositories that v0.2.0 would have failed in CI, 5 failed only because of false findings, so "six top packages fail a fresh-clone check" would have been a misleading headline. With v0.2.4, three fail, and each points at something a new contributor would actually hit. The landscape !Root lockfiles in the top 100: npm only 42, pnpm 14, Yarn 13, npm and pnpm 1, none 30. - Lockfiles at the root: 42 npm only, 14 pnpm, 13 Yarn, 1 npm and pnpm together, 0 Bun, 30 none. - packageManager: declared by 29 repositories (14 Yarn, 12 pnpm, 3 npm). - Node.js version: 68 declare engines.node, 8 commit .nvmrc, 5 .node-version; none really disagree. What CloneProof got wrong This is the part we learned the most from. In the pre-registered run, 26 of 83 findings were false. All but three are fixed in v0.2.4. 1. README examples for users (9 blocking findings, 5 repositories). webpack-dev-server, lint-staged, nyc, coveralls, and gh-pages all document how to add a script to your project and run it. For example, gh-pages shows a "deploy": "gh-pages -d dist" script and then npm run deploy (readme.md:373-384), and nyc shows a whole example scripts block (README.md:337-345). CloneProof read those as instructions for the repository itself and failed the build. Fixed in v0.2.1: scripts defined in a README example now belong to the reader's project. 2. Environment variables the user never sets (14 warnings). CloneProof reported GIT_DIR (set by Git during hooks), HOMEPATH and PROGRAMFILES (set by Windows), COMP_CWORD (set by the shell), CI-service variables, and keys a tool sets for itself, such as WEBPACK_SERVE and ROLLUP_WATCH, as undocumented configuration. Two were plain bugs: process.env.Wimp$ScrapDir in shelljs (src/tempdir.js:48) was parsed as a key named Wimp, and PostCSS was flagged for a variable mentioned only in a doc comment (lib/css-syntax-error.d.ts:226). Fixed in v0.2.4, except three that static reading cannot see: Vue's build-time feature flags, CI variables that coveralls detects, and AVA's child-process marker. 3. "No tests" when the tests are not JavaScript (2 warnings). The shell and Dart suites above. Fixed in v0.2.4. Only test files count; a husky or sass dependency, Git hooks, and fixture folders never do. None of the 10 repositories without tests in our earlier random sample started failing. 4. A Node version mismatch that is not one (1 warning). semantic-release declares engines.node as ^22.14.0 || >= 24.10.0. CloneProof could not parse >= 24.10.0 because of the space after the operator, so it compared .nvmrc's 24 with ^22.14.0 alone. Fixed in v0.2.4. After each fix we re-ran this sample and our earlier random sample of 50 repositories. The README fix (v0.2.1) removed exactly the 9 false blocking findings; the rest (v0.2.4) removed 14 of the 17 false warnings. On the random sample, every blocking finding is real and all 40 warnings are correct. Limitations - Static only. Nothing was installed or run, so this says nothing about whether tests pass. CloneProof's optional Docker verify mode checks that; it was not used here. - Not a typical sample. These are the most-depended-on, most-maintained repositories in the ecosystem. - Repositories move. Results are pinned to commits from 2026-10-30; four repositories moved before the final rerun, with unchanged findings. - One AI judge, not blind, who also wrote the fixes. The rules did not change and every reason is public, so treat the "after" numbers with the same skepticism as the "before" ones, and re-judge anything you disagree with. - 7 repositories were not checked because of CloneProof's clone safety limits. Try it Check any public repository without installing anything: npx cloneproof-check check https://github.com/OWNER/REPO The npm package is cloneproof-check, published from CI with provenance; the command it installs is cloneproof. Or add it to CI with the GitHub Action (CloneProof Check on the Marketplace): - uses: psuvraneel-cyber/Clone-Proof@v0.2.4 How to reproduce Everything is in the repository: - docs/field-test/run6-ranking.json: the ranking snapshot; - docs/field-test/run6-sample.json: the 100 repositories, their commits, and the expected findings; - docs/field-test/run6-results.json: every finding; - docs/field-test/run6-judgments.json: every judgment, its reason, and the interpretations used; - docs/field-test/run6-fix-results.json, run6-fixes-results.json, and run6-fixes-judgments.json: the reruns after the fixes, and the re-judged findings. The full write-up, with intervals and per-code tables, is in docs/FIELD_TEST.md. To rebuild the sample and rerun the checks: node scripts/fieldtest.js ranking --pages 5 --out ranking.json node scripts/fieldtest.js sample-list --ranking ranking.json --count 100 --out sample.json node scripts/fieldtest.js run --sample docs/field-test/run6-sample.json --out results.json node scripts/fieldtest.js summary --results docs/field-test/run6-results.json --judgments docs/field-test/run6-judgments.json --sample docs/field-test/run6-sample.json A fresh ranking run gives a slightly different sample; the committed files reproduce the published tables exactly. Thanks to the maintainers of all 100 projects. Nothing here is a criticism of their work. If CloneProof flagged your project and you think it is wrong, you are probably right; please open an issue.

Dependabot の通知を、32リポジトリぶん追えなくなった。AIと作った「依存の見回り TL;DR 個人で32リポジトリを持っている。棚卸ししたら、15リポジトリに high 以上の Dependabot アラートが合計345件あった（アラートは脆弱性ごと・ファイルごとに1件なので、パッケージの数よりずっと多い）。Dependabot は入っていた。通知も来ていた。追いきれていなかった 足りなかったのは通知ではなく、「全リポジトリを横断した一覧」と「どれから直すかの順番」だった clone せずに API だけで全リポジトリを週1回見回り、P1〜P3 の順位をつけて、P1 があるときだけ知らせる仕組みにした。件数を数える部分は32リポジトリで約50秒 AI にコードを書かせるときは、版を AI の記憶から書かせない。入れる直前に最新を確かめる そして、この記事を書いている途中で、自分がその罠を踏んだ。記憶の経験則（「Node の奇数の版は短命」）で決めた設定が、もう古かった Dependabot のメジャー更新の PR より小さい直し方があったこと、件数を数えるスクリプト、優先度の決め方、踏んだ落とし穴5つを置いておく。 プレビューが落ちた。原因は tailwind 4 だった 10月24日、Vercel から「プレビューのビルドに失敗」と通知が来た。半年以上触っていない個人アプリのリポジトリだ。 コードは何も変えていない。来ていたのは、Dependabot の PR だった。tailwindcss を 3 から 4 に上げる PR で、そのプレビューが落ちていた。 原因はすぐわかった。postcss.config.js が tailwindcss: {} を直接読んでいる。v4 では PostCSS のプラグインが @tailwindcss/postcss という別のパッケージになった（Tailwind CSS の移行ガイド）。 わからなかったのは、なぜメジャー更新の PR が来たのかだ。版の更新の設定（dependabot.yml）は入れていない。このリポジトリで動いているのは、脆弱性を直すための「セキュリティアップデート」だけのはずだった。 調べたら、こういうことだった。 postcss-selector-parser に脆弱性が公表された（GHSA-rj75-hqrm-r3gf、2026年10月5日、深刻度は moderate）。アドバイザリの記録では、対象は < 7.1.6、修正版は 7.1.6 tailwind 3 は postcss-selector-parser の 6 系（^6.1.2）を指定している だから Dependabot は「tailwind ごと 4 に上げる」PR を出した セキュリティアップデートでも、メジャー更新の PR は来る。 中の部品を直すために、外側のパッケージが丸ごと上がることがある。マージする前に気づけたのは、プレビューが落ちてくれたからだ。 しかも、続きがあった。postcss-selector-parser のリリースを見ると、10月19日に 6.1.5 が出ていて、同じ脆弱性の修正が 6 系にもバックポートされていた。6.1.5 は tailwind 3 の指定範囲に入る。つまり、tailwind を 3 のまま直せた。アドバイザリの記録がまだ 6.1.5 を修正版として載せていないので、Dependabot は大きいほうの直し方を出してきた、ということだ。 Dependabot が出した直し方が、いちばん小さい直し方とは限らない。 メジャー更新の PR が来たら、上げる前に、その部品のリリースノートでバックポートが出ていないかを見る。 ここで嫌な予感がした。半年触っていないリポジトリでこれなら、ほかはどうなっているのか。 棚卸ししたら、345件あった Claude Code に、自分の GitHub の全リポジトリを棚卸ししてもらった（数字は2026年10月24日時点）。アーカイブとフォークを除いて32個。 見たもの 結果 high 以上の Dependabot アラートがあるリポジトリ 15個（合計345件） 開きっぱなしの Dependabot の PR 53本 サポートが終わったランタイムに上げようとしている PR 4本 台帳に載っていない（存在を忘れていた）リポジトリ 5個 345件は「直すべきパッケージの数」ではない。Dependabot のアラートは、脆弱性ごと・ファイルごとに1件になる。1つのパッケージだけで、アラートが30件以上あったこともある。それでも、多いことには変わりない。 Dependabot は入っていた。アラートのメールも来ていた。でも、リポジトリごとにバラバラに届くので、「どれが本番で、どれが危ないか」を毎回頭の中で組み立てないといけない。32個になると、それはもうやらない。 通知が来ていることと、見ていることは違う。 最後の行も地味に効いた。台帳から漏れていたリポジトリは、見回りの対象からも漏れる。その中には、本番で動いているアプリも含まれていた。 clone しないで、全リポジトリを見回る やりたいことはシンプルにした。 全リポジトリについて「使っているパッケージ」「脆弱性」「ランタイム」「止まっている PR」を1つのファイルにまとめる 優先度をつけて、上から順に直せるようにする 週1回、自動で回して、P1 があるときだけ通知する 読む先は API だけ（clone しない） 最初は全リポジトリを clone して npm audit を回していた。32個 clone して、npm ci して……は重い。 GitHub には、clone しなくても読める情報がそろっている。 知りたいこと 読む先 脆弱性（深刻度・直接か間接か・実行時か開発用か・直る版） Dependabot alerts の REST API 実際に入っている版（lockfile から GitHub が作ったもの） SBOM の REST API 止まっている PR gh pr list --app dependabot 最新版 npm / PyPI の公開 API ランタイム Dockerfile の FROM と .nvmrc（contents API で読む） GitHub 以外に読むのは、最新版（npm / PyPI）とランタイムのサポート予定（endoflife.date）の公開 API だけだ。 まず、自分にどれだけ溜まっているかを見る 件数を数えるだけなら、これで足りる。 deps-alerts.sh #!/bin/bash 使い方: deps-alerts.sh <owner> リポジトリ（アーカイブ・フォークを除く）ごとに、 開いている Dependabot アラートの critical / high の件数と、Dependabot の PR の本数を出す。clone はしない 読めなかったリポジトリ（権限がない・Dependabot alerts が無効など）は 0 ではなく「?」と出す 要るもの: gh（gh auth login 済み）・jq。確認した環境: bash 3.2 / gh 2.103 / jq 1.7 set -uo pipefail owner="${1:?owner を渡す}" printf '%-36s %8s %5s %4s\n' repo critical high PR for repo in $(gh repo list "$owner" --limit 200 --no-archived --source --json name --jq '.[].name'); do if sev=$(gh api --paginate "repos/$owner/$repo/dependabot/alerts?state=open&per_page=100" \ --jq '.[].security_advisory.severity' 2>/dev/null); then crit=$(grep -c '^critical$' <<< "$sev"); high=$(grep -c '^high$' <<< "$sev") else crit='?'; high='?' fi prs=$(gh pr list -R "$owner/$repo" --app dependabot --state open --json number --jq length 2>/dev/null || echo '?') printf '%-36s %8s %5s %4s\n' "$repo" "$crit" "$high" "$prs" done | sort -k2,2nr -k3,3nr 動かし方： chmod +x deps-alerts.sh ./deps-alerts.sh <自分のユーザー名か org 名> 出力はこうなる（名前は伏せた）。critical が多い順に並ぶ。自分の32リポジトリでは、約50秒かかった（2026-10-24〜25 に計測）。 repo critical high PR repo-a 7 41 3 repo-b 3 20 5 repo-c 0 1 1 repo-d 0 0 0 注意が3つある。 「?」は「読めなかった」で、0件ではない。権限が足りない（管理者でない org など）か、Dependabot alerts が無効になっている。リポジトリの Settings → Advanced Security（Code security）で Dependabot alerts を有効にする 最初のバージョンは、読めなかったリポジトリを 2>/dev/null で捨てていて、0件と表示していた。セキュリティの道具で「読めなかった」を「きれい」に見せるのが、いちばん危ない 修正をマージしても、アラートが閉じるのは GitHub が数え直してから。直後に数えると、件数は変わっていないことがある 優先度は「本番で、実行時に使うか」で決める 件数だけ並べても、345件は直せない。順番が要る。 優先度 当てはまるもの いつまでに P1 critical の脆弱性／本番のあるリポジトリで、実行時に使うパッケージの high／本番のあるリポジトリで、サポートが終わったランタイム 見つけた週のうちに PR P2 開発用だけ・本番のないリポジトリの high／本番のあるリポジトリで、LTS でない Node 次にそのリポジトリを触るとき P3 moderate／メジャー版の遅れ／サポート終了まで90日以内のランタイム／14日以上止まっている Dependabot の PR 月1回まとめて 「実行時か開発用か」は、アラートの dependency.scope に runtime / development で入っている。値が入っていない（null）こともあるので、そのときは実行時として扱う（甘いほうに倒さない）。 「本番があるか」は API ではわからない。自分のリポジトリの台帳（どれが本番で、どこにデプロイしているか）を Markdown の表で持っていて、そこから読んでいる。台帳が見回りの対象を決めるので、台帳に載っていないリポジトリも一覧の上に出すようにした。 | repo | 役割 | 本番 | |------|------|------| | my-app | 家計のアプリ | Cloud Run | | my-tool | 手元の道具 | — | 週1回、P1 があるときだけ知らせる 自分の環境では、毎週日曜の朝に Mac mini の定期実行（LaunchAgent）で回し、結果を Markdown に書き出している。cron でも GitHub Actions の schedule でも同じことができる。 通知（自分は ntfy でスマホへ）は P1 があるときだけ。P2・P3 だけの週は送らない。毎週「P3 が40件あります」と来たら、3週目には見なくなる。それでは Dependabot のメールと同じだ。 通知にはこう出す。 依存の更新: P1 が 6 リポジトリ （リポジトリ名）：（パッケージ名）（直接）の脆弱性 critical ×N → X.Y.Z 以上に上げる（全部直る版） ... 一覧: ~/.local/state/.../inventory.md 「何が・何件・どうすればいいか」まで書く。自分の場合、最後は Claude Code に「依存の P1 を直して」と頼むだけになっている。 作るときに、古いものを入れない 見回りは「入ってしまった古いもの」を見つける仕組みだ。もう一つ、入口も閉じた。 AI にアプリを作らせると、AI が覚えている版で package.json を書くことがある。学習した時点では最新でも、書いている今は古い。古いリポジトリの package.json を参考にさせても同じことが起きる。 新しいリポジトリを作るときの雛形に、こう書いた。 版は記憶や古いリポジトリから写さない。入れる直前に最新の安定版を確かめる（npm view <名前> version、公式ドキュメント） 雛形（create-next-app など）は @latest で作る Node は LTS の版を使う。どれが LTS かは、記憶で決めず Node.js のリリース予定で確かめる lockfile をコミットし、npm ci で入れる .github/dependabot.yml を最初から入れる 最初の PR で npm audit --audit-level=high が 0 件 Node の行は、最初はこう書いていた。「偶数の版を使う。奇数の版は短命なので使わない」。これが間違いだった話は、落とし穴の最後に書く。 全部は直さない、と先に決めた 345件を直すにあたって、ルールを決めた。 セキュリティ修正（P1・P2）が先。マイナー・パッチの更新はまとめて1本。メジャー更新は1パッケージ1本で、公式の移行ガイドを読んでから 各 PR で install → lint → typecheck → test → build を全部通す。Vercel などのプレビューも通す 見た目が変わっていないことを機械で確かめる。main とブランチのビルドを並べて、主要画面を 1280px と 320px で撮り、ピクセル単位で比べる 置き換えた Dependabot の PR は、新しい PR にリンクしてから閉じる 半年以上触っていないリポジトリは、脆弱性の修正だけ。ふだんのメジャー更新はしない。ただし、脆弱性を直すのにメジャー更新が要るなら、それは上げる。上げられないなら公開を止める ビルドが通らない更新は無理に直さない。原因と選択肢を書いて止まる 3 は思ったより効いた。依存を上げると、JS のファイル名（ハッシュ）は全部変わる。差分を目で見ても「変わった」としか言えない。スクショのピクセルが一致すれば、少なくともその画面は変わっていないと言える。 ひとつ引っかかったのは、アニメーションのあるページだ。そのままだと main 同士で撮っても一致しない。アニメーションを止めてから撮り、「止めた状態なら main 同士は一致する」ことを先に確かめてから比べた。 5 は、全部を最新にしようとすると終わらないからだ。半年触っていないアプリを React 19 と tailwind 4 と vite 8 に上げる作業は、ほぼ作り直しになる。公開しているなら脆弱性だけは直す。それ以上は、そのアプリをまた触るときにやる。 この線引きで、Claude Code に8リポジトリぶんの PR を並行で作ってもらい、自分が見てマージした。 踏んだ落とし穴5つ 1. 「直る版」は、いちばん新しい修正版を見る あるライブラリについて、最初の棚卸しで「次のマイナー版に上げれば直る（メジャー更新はいらない）」と判断した。Dependabot は次のメジャー版への PR を出していたので、「メジャーを避けられる」と思った。 間違いだった。 アラートを1件ずつ見ると、同じライブラリに、修正版の違うアラートが混ざっていた。 アラート 直る版 一部 次のマイナー版 残りの大半 次のメジャー版 マイナー版で直るのは一部だけ。同じパッケージに複数のアラートがあるとき、全部直るのは「各アラートの直る版のうち、いちばん新しいもの」。見回りの一覧では「○○ 以上に上げる（全部直る版）」と、この値を出すようにした。 2. dependabot.yml の ignore は、セキュリティ修正の PR にも効く 「当面メジャー更新しないもの」を Dependabot に伝えるのは ignore だ。ただ、GitHub の設定リファレンスでは、ignore はセキュリティアップデートの PR にも影響する設定として印がついている。 雑にパッケージを丸ごと ignore すると、そのパッケージに脆弱性が出たときの修正 PR まで止まる。だから範囲を絞る。 version: 2 updates: - package-ecosystem: docker directory: / schedule: interval: weekly Node 25 までの奇数の版（23・25）は LTS にならないので上げない 出典: nodejs/Release%EF%BC%882026-10-25 確認） 見直す日: 2027-10-20 ignore: - dependency-name: node versions: [">= 23, < 24", ">= 25, < 26"] それでも、脆弱性のアラートは ignore と関係なく届く。止まるのは PR だけだ。見回りはアラートを読むので、ignore したパッケージに脆弱性が出ても P1 には上がってくる。 ignore には必ず「理由」「出典」「見直す日」を書く。書かないと、半年後に誰も外さない。 3. ほかの部品が「その版ちょうど」を指定していることがある あるリポジトリで、テスト用の部品（miniflare）が alpha 版に固定されていて、その中の部品（undici・sharp）に high の脆弱性があった。npm audit の提案は「miniflare を安定版の 4 系にする」。alpha の 5 系から見ると、版を戻すことになる。 調べると、Cloudflare の wrangler（使っていた 4.135.0）が、その alpha 版をちょうど指定していた。miniflare を動かすと wrangler と食い違う。 こういうときは外側を動かさず、package.json の overrides で中の部品だけを直る版に寄せた。 "overrides": { "undici": "7.30.1", "sharp": "0.35.5" } undici は同じ 7 系のマイナー、sharp は 0.35 系のパッチなので、ビルドとテストが全部通ることを確かめて入れた。overrides は便利だが、外し忘れると今度はそれが古くなる。PR に理由を書いておく。 4. 使っていない依存は、上げるより消す 半年触っていないアプリに、@vercel/node が開発用の依存として入っていた。中の部品に high があり、直すにはメジャー更新が要る。 コードを探したら、どこからも使われていなかった。api/ フォルダも vercel.json もない。上げるのをやめて、消した。 いちばん安全な依存は、入っていない依存だ。 5. 経験則も古くなる：Node 27 は奇数でも LTS になる Dependabot が、Docker のベースイメージを node:22-alpine から node:25-alpine に上げる PR を4本出していた。Node 25 は奇数の版で、LTS にならず、2026年6月1日にサポートが終わっている。上げる理由はない。 ここまではよかった。そこで自分（と Claude Code）は、「Node の奇数の版は短命」という覚え方のまま、23・25・27 を ignore する設定を4リポジトリに入れ、規約にも「奇数の版は使わない」と書いた。 翌日、この記事の事実確認を別の AI にやらせたら、指摘が来た。Node.js のリリース予定では、v27 からすべての版が Alpha → Current → LTS になる。27 が LTS になる予定日は 2027年10月20日。奇数が LTS にならないのは 25 までの話で、27 を ignore すると、将来の LTS への更新を止めてしまうところだった。 同じ日に、Python 3.10 のサポート終了日も1か月ずれていたのが見つかった（正しくは 2026年10月1日）。 AI が古くなるのは、版の数字だけではない。「いつもこう」という方針の覚え方も古くなる。 直したのは3つだ。 ランタイムのサポート予定を手書きの表で持つのをやめ、見回りのたびに endoflife.date の API から取る ignore には「理由・出典・確認日・見直す日」を必須にし、抜けや期限切れを一覧に出す 版や ignore の方針を決める PR は、実装した AI とは別の AI に一次ソースと照合させてからマージする 最後のものが、今回いちばん効いた。自分で決めたことを自分で確かめても、同じ記憶で確かめるだけだった。 結果 8リポジトリに、脆弱性の修正の PR を出してマージした。npm audit の high 以上は、この8リポジトリで計97件 → 4件。残った4件は、直すのにメジャー更新が要るもの（冒頭の345件は Dependabot アラートの件数で、数え方が違うので並べて比べない） Node 25 への PR は4本とも閉じ、ignore を「23・25 だけ」に直して入れた 台帳から漏れていた5リポジトリを台帳に戻し、見回りの対象にした 本番で動いていて、直すのにメジャー更新が要る critical が1つ残っていた。Next.js 14 の画像最適化 API で、認証なしでコードを実行される脆弱性だ（14 系には修正版がない）。「手間が大きい」と後回しにしていたのを、この記事の公開前チェック（攻撃者の目で読ませる係）に指摘された。Next.js 15 に上げてデプロイしてから、この記事を出している ほかのメジャー更新が要るものは、1パッケージ1本で、移行ガイドを読みながら進める 全部が片付いたわけではない。ただ、どこに何が残っているかを、毎週わかる仕組みにした。 自分の現場に持ち帰るなら 上のスクリプトで、自分のリポジトリにどれだけ溜まっているかを見る。「?」が出たら、まずそこを読めるようにする 件数の多い順ではなく、「本番で、実行時に使うもの」から直す 版・サポート期間・ignore は、記憶ではなく一次ソースで決める。決めた PR は、別の目（人でも AI でも）に照合させる Dependabot は便利だ。でも、Dependabot が教えてくれるのは「このリポジトリに何があるか」までで、「32個の中でどれから直すか」は教えてくれない。そこを決めるのは、自分の台帳だった。 nekoai-lab.github.io