WindowsのAstroプロジェクトでWrangler追加時にnpm EPERMが出たときの確認方法

WindowsのAstroプロジェクトでWrangler追加時に出たnpm warn cleanupとEPERM。実際のログを見ながら、どこまで対応したかを残します。

公開：更新：
WindowsのAstroプロジェクトでWrangler追加時にnpm EPERMが出たときの確認方法

WindowsのAstroプロジェクトへWranglerを追加したらEPERMが何行も出て、 「インストールに失敗したのか」 「node_modulesを全部消すべきか」 「このまま次へ進んで大丈夫なのか」 と不安になっていないでしょうか。npmの警告は、途中の1行だけでなく最後まで処理が完了したかを見る必要があります。

ゆまラボではnpm install --save-dev wranglerの途中でnpm warn cleanupとEPERM: operation not permitted, rmdir ...が出ました。それでもログの最後はadded 31 packages、audited 240 packages in 23s、found 0 vulnerabilitiesまで進み、Wranglerの追加自体は成功していました。

この記事では、EPERMを見たときに「どの処理が失敗したのか」「npm全体は完了しているのか」をログ末尾から確認する方法を紹介します。いきなり全削除・再インストールする前の切り分けに使えます。

npm install --save-dev wrangler

途中のログはかなりエラーっぽい。最初に見たときは、Wranglerの追加そのものに失敗したと思った。

npm warn cleanup Failed to remove some directories
Error: EPERM: operation not permitted, rmdir '...node_modules...'

Wrangler追加時に実際に表示されたnpm warn cleanupとEPERM

ただ、このときはWranglerの追加そのものは終わっていた。

ログの最後にadded 31 packagesとfound 0 vulnerabilitiesが出ている。見た目だけでnode_modulesを全部消さずに済んだケース。

出ていたのはnpm warn cleanup#

今回のログで先に見たのはEPERMより、その少し前にあるnpm warn cleanup。

npmが依存関係を処理したあと、一部ディレクトリの削除に失敗している。

code: 'EPERM'
syscall: 'rmdir'

Astroのソースをコンパイルして失敗したわけではない。

Windows上でnode_modules内のディレクトリを消そうとして、OSから拒否された形になる。

開発サーバーや別のNode.jsプロセスがファイルを参照していると、Windowsではこういう状態になることがある。

ログの最後まで進んでいるなら、まずそのまま動作確認した#

自分のときは警告のあともnpmの処理が続いていた。

added 31 packages, changed 1 package, and audited 240 packages in 23s
found 0 vulnerabilities

ここまで出ているなら、少なくとも今回のインストールは途中で完全停止していない。

そのため、いきなり削除や再インストールはせず、次の作業へ進めるかを確認した。

npm run dev

必要なら本番ビルドも見る。

npm run build

起動もビルドも通るなら、表示されたEPERMだけを理由に環境を作り直す必要はなかった。

本当に失敗しているときだけNode.jsを止めて再構築する#

もちろん、毎回無視してよいわけではない。

npm install自体が失敗している、必要なパッケージが入っていない、npm run devが起動しない、といった状態ならファイルロックを疑う。

まず開発サーバーをCtrl+Cで止める。それでもNode.jsプロセスが残っているか確認するならPowerShellで見られる。

Get-Process node -ErrorAction SilentlyContinue

不要なNode.jsプロセスを止める場合は次の形になる。

Get-Process node -ErrorAction SilentlyContinue | Stop-Process -Force

これは別のNode.jsアプリも止める可能性があるので、何が動いているか分からない状態でいきなり実行しない方がいい。

そのうえで依存関係を作り直すなら、当時残していた手順は次の形。

Remove-Item -LiteralPath 'C:\000pj\astro\yumaru-site\node_modules' -Recurse -Force
npm cache verify
npm install
npm run dev

package-lock.jsonは最初から消していない。

ファイルロックの問題と依存関係の解決結果は別なので、まずnode_modulesだけ作り直した方が原因を追いやすい。

npm cache clean --forceは使わなかった#

npmのエラー対応を調べるとnpm cache clean --forceもよく出てくるが、今回は使っていない。

npmの公式ドキュメントではキャッシュは自己修復を前提としていて、状態確認にはnpm cache verifyが用意されている。

npm cache verify

今回のEPERMはrmdirで出ていたので、最初からキャッシュ削除へ進む理由もなかった。

実際にはインストール自体が成功しており、大きな再構築は不要。

EPERMを見たときに自分が先に確認すること#

同じ表示が出たら、最初にログの最後を見る。

npm warn cleanupなのか、npmコマンド自体が失敗して終わっているのかで対応が変わるからだ。

今回のようにパッケージ追加まで完了しているなら、まずAstroを起動する。そこで問題がなければ、その警告を深追いしない。

実際に動かないときだけ、Node.jsプロセス、node_modules、キャッシュ確認の順で触る。

EPERMという文字だけで全部消すより、この順番の方が余計な作業が少なかった。

参考#