Nvm-windows: Folder instalasi salah

Dibuat pada 5 Apr 2016  ·  12Komentar  ·  Sumber: coreybutler/nvm-windows

Lingkunganku

  • [ ] Windows 10

Folder AppData adalah untuk data, bukan executable. Ini seharusnya tidak diinstal di sana secara default, apalagi cabang roaming di mana ia secara otomatis disalin ke setiap mesin di domain Windows yang sama.

Installer Issue

Komentar yang paling membantu

Berikut adalah rekomendasi dasar:

  • Program masuk %ProgramFiles% , yang biasanya C:\Program Files .
  • Pada mesin 64-bit, program x86 lama masuk %ProgramFiles(x86)% , yang biasanya C:\Program Files (x86) .
  • Data program seluruh mesin, seperti cache paket, masuk %ProgramData% , yang biasanya C:\ProgramData
  • Pengaturan pengguna yang dapat dengan aman menjelajah dari mesin ke mesin masuk %APPDATA%
  • Pengaturan pengguna yang bersifat lokal untuk mesin tertentu (misalnya yang berisi jalur instalasi) masuk %LOCALAPPDATA% .

Semua 12 komentar

Apakah saya salah, atau apakah NVM hanya memasukkan cache paket node 400MB ke profil roaming saya?

Tidak, itu bug di NPM.

Instalasi default menunjuk ke direktori appdata pengguna lokal, bukan roaming. Meskipun mungkin lebih baik untuk memiliki executable di lokasi yang berbeda, semua file instalasi node dan npm dianggap data untuk NVM (ini adalah desain npm). Sekali lagi, ini adalah default karena suatu alasan... Anda dapat mengubahnya jika Anda tidak menyukainya.

Saya tidak tahu dari mana Anda mendapatkan 400MB. Bisakah Anda memberikan detail lebih lanjut tentang lingkungan Anda?

Pada poin pertama, mungkin perbedaannya adalah saya menginstalnya di komputer yang terhubung dengan domain dan Anda tidak. Tapi bagaimanapun caranya tetap salah. AppData adalah untuk pengaturan pengguna, bukan yang dapat dieksekusi.

Adapun poin kedua, Node sendiri yang membuat kesalahan itu. Saya akan mengajukan bug dengan mereka secara terpisah.

Ini tidak selalu "salah", tetapi jika memiliki efek buruk, saya senang untuk mempertimbangkan kasus penggunaan Anda. Saya tidak memiliki pengalaman yang sama dengan komputer yang terhubung ke domain, jadi sekali lagi, detail lingkungan akan membantu saya memahami kasus penggunaan spesifik Anda.

Misalnya, jika saya tahu apa yang harus dicari, saya dapat membuat versi penginstal berikutnya mengetahui domain. Dengan kata lain, lokasi instalasi default bisa lebih pintar.

Berikut adalah rekomendasi dasar:

  • Program masuk %ProgramFiles% , yang biasanya C:\Program Files .
  • Pada mesin 64-bit, program x86 lama masuk %ProgramFiles(x86)% , yang biasanya C:\Program Files (x86) .
  • Data program seluruh mesin, seperti cache paket, masuk %ProgramData% , yang biasanya C:\ProgramData
  • Pengaturan pengguna yang dapat dengan aman menjelajah dari mesin ke mesin masuk %APPDATA%
  • Pengaturan pengguna yang bersifat lokal untuk mesin tertentu (misalnya yang berisi jalur instalasi) masuk %LOCALAPPDATA% .

Tidak jarang executable berada di appdata. Aplikasi yang diinstall menggunakan clickonce do it, yang merupakan installer buatan microsoft. Chrome melakukannya. Banyak hal yang melakukannya.

@aljones Salah satu alasan utamanya adalah ini – Menginstal program di profil pengguna mungkin nyaman, tetapi pasti memiliki konsekuensi keamanan karena proses apa pun dapat memodifikasi barang sesuka hati. Perhatikan bahwa ClickOnce _melakukan_ pemasangan di profil pengguna tetapi juga memastikan bahwa rakitan memiliki lebih sedikit hak istimewa pada sistem.

Meskipun ada kasus penggunaan umum untuk menginstal aplikasi per pengguna tanpa memerlukan hak administratif, ini adalah perilaku default yang sangat buruk dan Chrome menetapkan preseden buruk di sini, imho.

Saya yakin pengalaman saya baru-baru ini relevan dengan diskusi: Saya baru-baru ini memiliki sakelar stasiun kerja. Jalur untuk node_packages di profil roaming saya sangat dalam, sehingga pemulihan profil roaming yang coba dilakukan mesin saya akan gagal setiap kali sampai saya menghapus folder node_packages. Kesalahan ini muncul di log Peristiwa Windows. Setelah saya melakukan itu, workstation baru saya akhirnya dapat menyinkronkan profil roaming saya.

Saya setuju bahwa menginstal ke roaming menyebabkan masalah ketika Anda bekerja di perusahaan yang mencadangkan profil Anda untuk digunakan dalam jaringan mereka. Misalnya, komputer saya memerlukan waktu 30 menit untuk mati dan 30 menit untuk memulai ulang; semua karena modul npm. Sayangnya, AFAIK, ini adalah masalah dengan NPM itu sendiri.

Sebagai tindak lanjut dari ini:

Secara umum, penting untuk dicatat bahwa manajer versi mana pun hanya mengelola program. Saya mengulangi komentar sebelumnya .... dalam arti NVM, program yang diinstal (simpul) _is_ data. Bagaimana Anda menggunakannya (yaitu modul npm) dapat berkontribusi pada footprint.

@ sam3k benar bahwa footprint pasti terkait dengan bagaimana npm dirancang, dan sebenarnya tidak banyak yang NVM _harus_ lakukan untuk ini, juga tidak banyak yang dapat dilakukan npm sendiri untuk ini. Ini bermuara pada mengetahui apa yang Anda instal, dan manajer paket apa pun membuatnya mudah untuk menerima begitu saja. Banyak orang tidak memperhatikan jejak modul, yang merupakan masalah kualitas kode/lingkungan yang melekat pada dunia open source. Intinya, terserah pada komunitas untuk menyelesaikan masalah ini melalui praktik pengkodean yang disiplin (jauh dari tugas sepele). Saya salah satu dari banyak orang yang menganjurkan ini (lihat npm membutuhkan pelatih pribadi . Poin: manajemen npm melampaui premis dasar mengelola versi node mana yang Anda jalankan.

@aljones dan @ygra keduanya punya poin bagus. Saya tidak setuju dengan mereka, tetapi saya ingin mengingatkan semua orang bahwa hak administratif adalah suatu keharusan untuk membuat symlink berfungsi. Ini adalah prinsip inti cara kerja NVM untuk Windows.

@cokobware memiliki apa yang saya yakini sebagai masalah umum di lingkungan perusahaan. Intinya adalah npm tidak dirancang untuk portabilitas yang mudah dalam skala besar. Salah satu contoh node+npm sudah cukup berat, apalagi menambahkan beberapa versi. Terlepas dari bagaimana data/file berpindah dari workstation ke workstation, ada begitu banyak dari mereka yang akan memakan waktu cukup lama. Pilihannya adalah menggunakan profil roaming Windows, zip semuanya dan transfer secara manual, atau unduh ulang dari registri npm. Tidak peduli bagaimana Anda memutarnya, menyinkronkan workstation hanya akan membutuhkan waktu untuk memasukkan semua bit ke tempat yang tepat.

Masa depan NVM untuk Windows (sampai sekarang) kemungkinan akan tetap fokus pada peralihan versi node. Saya bahkan dapat mengubah nama proyek untuk mencerminkan hal itu. Ini akan terus memberikan penginstal dengan default umum, tetapi masih tergantung pada organisasi/pengembang untuk menimpa default ini dengan cara yang sesuai untuk organisasi mereka. Saya melihat manajemen versi node sebagai masalah yang sangat berbeda dari manajemen footprint npm, meskipun saya bereksperimen dengan cara-cara di mana NVM4W dapat menyediakan kait untuk manajemen npm yang lebih baik.

Silakan ikuti saran @Grauenwolf dan referensi ini: panduan penerapan , CSIDL , dan Variabel Lingkungan

  • symlink %USERPROFILE%AppData ke %PROGRAMFILES% atau %PROGRAMFILES(X86)% adalah ide yang buruk. Masalah pada banyak pengguna (Masalah kepemilikan. Pengguna lain tidak dapat mengakses tautan).
  • Program nvm seharusnya disimpan dalam %PROGRAMFILES% atau %PROGRAMFILES(X86)%.
  • repositori nodejses seharusnya disimpan dalam %PROGRAMDATA% karena cakupannya adalah semua pengguna.
  • tautan nodejs aktif seharusnya disimpan di %LOCALAPPDATA% karena cakupannya adalah per pengguna.

NVM tidak dapat dipasang di %PROGRAMFILES% karena bug lain. Jika Anda meletakkannya di folder yang memiliki spasi di namanya, perintah instal gagal.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat