Reviewed — the fix looks correct, and it actually protects more than the reported esbuild case: since clone_dir_recursive falls back to hard_link_dir_recursive, files in node_modules are frequently hardlinks into the global npm cache, and overwrite-in-place could previously write through into the cache entry as well. Remove-before-copy closes that hole too.

A few suggestions:

1. Dead code: this PR removes the only two call sites of deno_npm_cache::is_etxtbsy. After this lands, the helper in libs/npm_cache/fs_util.rs and its re-export in lib.rs are unused — could you remove them here as well? The comment in hard_link_file ("Callers should handle this by falling back to copy") can stay, since the fallback is still a copy.

2. Per-file overhead (very minor): every copied file now pays an extra unlink even on fresh installs where the destination doesn't exist. It's one cheap syscall in an already I/O-heavy path, so I don't think it's worth complicating the code over — just noting it was considered.

3. Test coverage: the unit test is well targeted (asserting the other end of the link is untouched is exactly the pre-fix failure). An end-to-end spec test that re-installs after a lifecycle script hardlinks over a package file would guard the full path, but given how awkward lifecycle-script specs are to set up, the unit test seems like an acceptable trade-off.

Thanks for the review. Done in 4080c1b — removed is_etxtbsy and its re-export from deno_npm_cache. The remaining ETXTBSY mentions are all comments, including the one in hard_link_file you mentioned.