Pertanyaan yang Sering Diajukan
Mengapa folder node_modules
saya menggunakan ruang penyimpanan jika paket disimpan di store global?
pnpm membuat hard link (tautan keras) dari store global ke folder node_modules
proyek. Hard link mengarah ke tempat yang sama pada penyimpanan dimana berkas asli berada. Ambil contoh, jika Anda memiliki foo
di proyek Anda sebagai dependensi dan itu menempati ruang 1MB, maka itu akan terlihat seperti menempati 1MB ruang di folder node_modules
proyek dan jumlah ruang yang sama di store global. Namun, 1MB itu adalah ruang yang sama pada penyimpanan yang dialamatkan dari dua lokasi berbeda. Jadi total foo
menempati 1MB, bukan 2MB.
Untuk lebih lanjut tentang hal ini:
- Mengapa hard link tampaknya mengambil ruang yang sama dengan aslinya?
- Sebuah utas dari ruang obrolan pnpm
- Sebuah issue di repositori pnpm
Apakah hard link bekerja pada Windows?
Singkatnya ya. Menggunakan symbolic link (tautan simbolis) pada Windows bisa dikatakan bermasalah, namun pnpm punya solusinya. Untuk Windows, kami menggunakan junction sebagai gantinya.
Tetapi pendekatan node_modules
bersarang tidak kompatibel dengan Windows?
Versi awal npm memiliki masalah karena menyarangkan semua node_modules
(lihat issue ini). Namun, pnpm tidak membuat folder yang dalam, ia menyimpan semua paket secara datar dan menggunakan symbolic link untuk membuat struktur pohon dependensi.
Bagaimana dengan symlink melingkar?
Meskipun pnpm menggunakan penautan untuk meletakkan dependensi ke dalam folder node_modules
, symlink melingkar dihindari karena paket induk ditempatkan ke folder node_modules
yang sama di mana dependensinya berada. Jadi, dependensi milik foo
tidak akan ada di foo/node_modules
, tetapi dependensi-dependensi itu berada di node_modules
bersamaa dengan foo
itu sendiri.
Kenapa lebih banyak menggunakan hard link? Kenapa tidak menggunakan symlink langsung ke store global?
Satu paket bisa saja memiliki seperangkat dependensi yang berbeda pada satu mesin.
Dalam proyek A foo@1.0.0
dapat memiliki dependensi yang diselesaikan menjadi bar@1.0.0
, tetapi dalam proyek B dependensi yang sama dari foo
mungkin diselesaikan menjadi bar@1.1.0
; jadi, pnpm menggunakan hard link untuk foo@1.0.0
ke setiap proyek di mana ia digunakan, untuk membuat seperangkat dependensi yang berbeda.
Melakukan symlink langsung ke store global akan bekerja dengan tanda Node --preserve-symlinks
. Namun, pendekatan itu datang dengan sejumlah masalah besar. Jadi kami memutuskan untuk tetap menggunakan hard link. Untuk detail lebih lanjut tentang mengapa keputusan ini dibuat, lihat issue ini.
Does pnpm work across different subvolumes in one Btrfs partition?
While Btrfs does not allow cross-device hardlinks between different subvolumes in a single partition, it does permit reflinks. As a result, pnpm utilizes reflinks to share data between these subvolumes.
Does pnpm work across multiple drives or filesystems?
The package store should be on the same drive and filesystem as installations, otherwise packages will be copied, not linked. This is due to a limitation in how hard linking works, in that a file on one filesystem cannot address a location in another. See Issue #712 for more details.
pnpm functions differently in the 2 cases below:
Jalur store ditentukan
If the store path is specified via the store config, then copying occurs between the store and any projects that are on a different disk.
If you run pnpm install
on disk A
, then the pnpm store must be on disk A
. If the pnpm store is located on disk B
, then all required packages will be directly copied to the project location instead of being linked. This severely inhibits the storage and performance benefits of pnpm.
Jalur store TIDAK ditentukan
If the store path is not set, then multiple stores are created (one per drive or filesystem).
If installation is run on disk A
, the store will be created on A
.pnpm-store
under the filesystem root. If later the installation is run on disk B
, an independent store will be created on B
at .pnpm-store
. The projects would still maintain the benefits of pnpm, but each drive may have redundant packages.
What does pnpm
stand for?
pnpm
stands for performant npm
. @rstacruz came up with the name.
pnpm
does not work with <YOUR-PROJECT-HERE>?
In most cases it means that one of the dependencies require packages not declared in package.json
. It is a common mistake caused by flat node_modules
. If this happens, this is an error in the dependency and the dependency should be fixed. That might take time though, so pnpm supports workarounds to make the buggy packages work.
Solusi 1
In case there are issues, you can use the node-linker=hoisted
setting. This creates a flat node_modules
structure similar to the one created by npm
.
Solusi 2
In the following example, a dependency does not have the iterall
module in its own list of deps.
The easiest solution to resolve missing dependencies of the buggy packages is to add iterall
as a dependency to our project's package.json
.
You can do so, by installing it via pnpm add iterall
, and will be automatically added to your project's package.json
.
"dependencies": {
...
"iterall": "^1.2.2",
...
}
Solusi 3
One of the solutions is to use hooks for adding the missing dependencies to the package's package.json
.
An example was Webpack Dashboard which wasn't working with pnpm
. It has since been resolved such that it works with pnpm
now.
It used to throw an error:
Error: Cannot find module 'babel-traverse'
at /node_modules/inspectpack@2.2.3/node_modules/inspectpack/lib/actions/parse
The problem was that babel-traverse
was used in inspectpack
which was used by webpack-dashboard
, but babel-traverse
wasn't specified in inspectpack
's package.json
. It still worked with npm
and yarn
because they create flat node_modules
.
The solution was to create a .pnpmfile.cjs
with the following contents:
module.exports = {
hooks: {
readPackage: (pkg) => {
if (pkg.name === "inspectpack") {
pkg.dependencies['babel-traverse'] = '^6.26.0';
}
return pkg;
}
}
};
After creating a .pnpmfile.cjs
, delete pnpm-lock.yaml
only - there is no need to delete node_modules
, as pnpm hooks only affect module resolution. Then, rebuild the dependencies & it should be working.