Juga terjadi secara lokal di Linux dengan langkah repro yang sama, mis

npm ERR! syscall lchown
npm ERR! path /home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, lchown '/home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock'
npm ERR! enoent This is related to npm not being able to find a file.

Tampaknya lebih jarang terjadi ketika saya beralih ke node 11.0.0 + npm 6.7.0.

Node 11.0.0 adalah versi yang sangat aneh karena node 11 adalah EOL sejak lama. Mungkin coba LTS 12.13.1 saat ini? Atau mungkin versi NPM yang lebih lama dibundel dengan node 11 yang menghindari ini.

Ya, saya baru saja melakukan perjalanan mundur melalui versi yang telah saya instal sampai saya menemukan versi yang tidak bermasalah. Versi npm yang lebih lama sangat mungkin merupakan variabel.

@sandersn mungkin melakukan pencarian biner manual melalui versi? 😛.

Mengalami bug ini saat menggunakan Lerna secara konsisten, yang sayangnya menyebabkan masalah dalam proses pembuatan kami.
Pesan eror:

lerna ERR! npm install stderr:
  | npm ERR! code ENOENT
  | npm ERR! syscall lchown
  | npm ERR! path /root/.npm/_locks/staging-3f138bd09ee0de58.lock
  | npm ERR! errno -2
  | npm ERR! enoent ENOENT: no such file or directory, lchown '/root/.npm/_locks/staging-3f138bd09ee0de58.lock'
  | npm ERR! enoent This is related to npm not being able to find a file.
  | npm ERR! enoent

Ini adalah saat menggunakan gambar buruh pelabuhan node:latest-alpine , yang saat ini menggunakan versi:
simpul: 12.13.1
npm: 6.12.1

Saya dapat mengonfirmasi bahwa ini juga terjadi pada saya dengan node v13.2.0 dan npm 6.13.4.

Adakah yang punya perbaikan sementara untuk ini? Karena memblokir beberapa penerapan kami. :(

Midudev temp mitigasi adalah untuk tidak menjalankan npm i secara paralel atau setidaknya secara drastis mengurangi konkurensi.
Ketika berurusan dengan repo DT yang membatasinya menjadi 2 pemasangan paralel, ini mengurangi jumlah kegagalan sekitar ~90%.

Terima kasih @SimonSchick. Ya... Tidak menggunakan konkurensi sama sekali tampaknya memperbaiki masalah tetapi waktu yang dibutuhkan untuk menginstal paket sangat meningkat. :(

Saya ingin tahu apakah tim npm mengetahui masalah ini karena ini berfungsi dengan baik sebelumnya. Tentu jika ini adalah masalah yang disebabkan karena beberapa perubahan dalam pada node.js.

Hai, kami memiliki masalah yang sama.
Saya hampir yakin bahwa ini adalah semacam masalah kondisi balapan.

Perbaikan sementara adalah menurunkan versi ke [email protected] .

Saya telah menguji hampir setiap versi dari 6.10.2 hingga 6.13.6 terbaru dan masalahnya ada di sana.
Saya dapat mengonfirmasi bahwa bug TIDAK terkait dengan versi nodejs , itu hanya terkait dengan versi npm .

Kami mengalami masalah yang sama untuk npm i terhadap https://github.com/strongloop/loopback-next , yang merupakan lerna monorepo. npm i pada tingkat root memicu instalasi npm untuk beberapa paket secara paralel. Mengurangi konkurensi juga mengurangi kemungkinan menjalankan masalah yang dilaporkan.

Kita bisa mendapatkan informasi lebih lanjut tentang lockfile dengan NODE_DEBUG=lockfile npm i .

Setelah beberapa debugging, saya menemukan masalah di sekitar https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. Jika npm dieksekusi secara bersamaan, beberapa proses memanggil chownr terhadap ~/.npm/_locks . Implementasi chownr membaca semua file dalam direktori dan mencoba menerapkan chown terhadap setiap file. Beberapa file mungkin dihapus antara readdir dan lchown dan itu mengarah ke ENOENT .

@isaacs Tolong beri tahu saya jika https://github.com/raymondfeng/chownr/commit/e4c7b59fe4142995ae36c71de3435d2e2a7e4319 adalah tempat yang tepat untuk memperbaiki masalah ini. Jika demikian, saya akan mencoba menambahkan beberapa tes dan mengirimkan PR.

@raymondfeng Itu terlihat seperti perubahan yang masuk akal. Ya, tolong kirimkan PR ke chownr.

@isaacs PR dikirimkan - https://github.com/npm/cli/issues/496. Terima kasih atas tanggapan yang cepat.