스토어 & lockfile 설정
Store settings#
storeDir#
- 기본값:
- $PNPM_HOME 환경 변수가 설정된 경우, $PNPM_HOME/store
- $XDG_DATA_HOME 환경 변수가 설정된 경우, $XDG_DATA_HOME/pnpm/store
- Windows: ~/AppData/Local/pnpm/store
- macOS: ~/Library/pnpm/store
- Linux: ~/.local/share/pnpm/store
- 유형: path
모든 패키지가 저장되는 디스크 위치입니다.
저장소는 항상 설치가 발생하는 동일한 디스크에 있어야 합니다. 따라서 디스크당 하나의 저장소가 있도록 합니다. 현재 디스크에 홈 디렉토리가 있으면, 그 안에 저장소가 생성됩니다. 디스크에 홈이 없으면 파일 시스템의 루트에서 저장소가 생성됩니다. 예를 들어, /mnt에 마운트된 파일 시스템에서 설치가 이루어지는 경우 스토어는 /mnt/.pnpm-store에 생성됩니다. Windows 시스템도 마찬가지입니다.
다른 디스크에서 저장소를 설정할 수 있지만, 이 경우 pnpm은 하드 링크 대신 저장소에서 패키지를 복사합니다. 하드 링크는 동일한 파일 시스템에서만 가능하기 때문입니다.
If no directory above the project accepts a hard link at all (an agent sandbox
that grants write access only to the project, or a container with just the
project bind-mounted writable), the store is created at .pnpm-store inside the
project. Putting it in the home directory there would either fail on a read-only
home or land on another volume, which copies every package instead of hard-linking
it (#13525).
important
이 pnpm 스토어는 서로 신뢰하는 사용자, 작업, 프로세스 간에서만 공유하도록 설계되었습니다. 공유 storeDir을 구성하는 경우, 신뢰할 수 없는 사용자가 쓸 수 없도록 파일 시스템 권한으로 보호하세요. 스토어는 pnpm 신뢰 도메인의 일부입니다: 패키지가 스토어에서 하드 링크될 수 있으며, 스토어 인덱스(index.db)는 캐시된 파일을 검증하는 데 사용되는 해시를 기록합니다.
verifyStoreIntegrity#
- 기본값: true
- 타입: Boolean
기본적으로 스토어의 파일이 수정된 경우, 프로젝트의 node_modules에 링크하기 전에 해당 파일의 내용을 확인합니다. verifyStoreIntegrity가 false로 설정되면 설치 중에 콘텐츠 주소 지정 스토어의 파일을 확인하지 않습니다.
이 설정은 우발적인 스토어 손상을 감지하는 데 도움이 됩니다. 스토어에 쓸 수 있는 공격자는 캐시된 패키지 내용과 이를 검증하는 데 사용되는 메타데이터를 모두 변경할 수 있으므로, 이 설정이 신뢰할 수 없는 사용자가 쓸 수 있는 스토어를 안전하게 만들지는 않습니다.
strictStorePkgContentCheck#
- 기본값: true
- 타입: Boolean
일부 레지스트리는 정확히 동일한 내용을 다른 패키지 이름 및/또는 버전으로 게시하는 것을 허용합니다. 이로 인해 스토어에 있는 패키지의 유효성 검사가 깨집니다. 스토어에서 이러한 패키지의 이름과 버전을 검증할 때 오류를 피하려면 strictStorePkgContentCheck 설정을 false로 지정할 수 있습니다.
frozenStore#
추가된 버전: v11.7.0
- 기본값: false
- 타입: Boolean
Lets pnpm install run against a package store that lives on a read-only filesystem, for example a Nix store, a read-only bind mount, or an OCI image layer. 활성화하면 pnpm은 스토어의 SQLite index.db를 불변 모드로 열고(읽기 전용 디렉터리에서는 생성할 수 없는 WAL/-shm 사이드카 파일을 우회함) 스토어에 쓰기를 수행하는 모든 코드 경로를 억제합니다.
Ordinary installs can run in parallel and populate the same store on a local filesystem on the same machine. Leave frozenStore disabled for that use case.
With frozenStore enabled, no other process may modify the store during the install. Immutable reads bypass SQLite locking and can report "database disk image is malformed" if another job changes the database. This restriction does not apply to --frozen-lockfile, which still allows writes to the store.
완전히 채워진 스토어를 대상으로 --offline 및 --frozen-lockfile과 함께 사용하세요:
pnpm install --frozen-store --offline --frozen-lockfile
스토어에는 라이프사이클 스크립트가 승인된(또는 패치가 적용된) 모든 패키지의 빌드 출력을 포함하여 설치에 필요한 모든 것이 이미 들어 있어야 합니다. Under the global virtual store, those package directories live inside the store, so if a required build is missing the install fails up front with ERR_PNPM_FROZEN_STORE_NEEDS_BUILD. Seed the store with those builds first. 스토어에 콘텐츠 디렉터리가 아예 없으면, 설치는 이를 초기화하려 하지 않고 ERR_PNPM_FROZEN_STORE_INCOMPLETE와 함께 빠르게 실패합니다.
frozenStore는 --force 및 구성된 pnpr 서버와 호환되지 않는데, 둘 다 스토어에 쓰기 때문입니다. 사이드 이펙트 캐시도 기록되지 않습니다.
참고
읽기 전용 스토어 열기에는 Node.js >=22.15.0, >=23.11.0, 또는 >=24.0.0이 필요합니다. 이전 런타임에서는 --frozen-store가 ERR_PNPM_FROZEN_STORE_UNSUPPORTED_NODE와 함께 실패합니다.
Lockfile settings#
lockfile#
- 기본값: true
- 타입: Boolean
false로 설정하면 pnpm은 pnpm-lock.yaml 파일을 읽거나 생성하지 않습니다.
frozenLockfile#
- 기본값:
- CI가 아닌 경우: false
- CI의 경우: lockfile이 있으면 true
- 타입: Boolean
When set to true, pnpm fails the installation if the lockfile needs updating
or is missing.
In CI environments, this setting defaults
to true when a lockfile is present.
preferFrozenLockfile#
- 기본값: true
- 유형: Boolean
true로 설정되어 있고 사용 가능한 pnpm-lock.yaml이 package.json의 종속성 지시문을 충족하면, headless 설치가 수행됩니다. 헤드리스 설치는 lockfile을 수정할 필요가 없기 때문에 모든 의존성 해결을 건너뜁니다.
lockfileIncludeTarballUrl#
- 기본값: false
- 타입: Boolean
pnpm-lock.yaml의 모든 항목에 패키지 tarball의 전체 URL을 추가합니다.
gitBranchLockfile#
- 기본값: false
- 타입: Boolean
When set to true, the generated lockfile name after installation will be named
based on the current branch name to completely avoid merge conflicts. 예를 들어, 현재 브랜치 이름이 feature-foo이면 해당 lockfile 이름은 pnpm-lock.yaml 대신 pnpm-lock.feature-foo.yaml이 됩니다. It is typically used
in conjunction with the command line argument --merge-git-branch-lockfiles or by
setting mergeGitBranchLockfilesBranchPattern in the pnpm-workspace.yaml file.
mergeGitBranchLockfilesBranchPattern#
- 기본값: null
- 유형: Array 또는 null
This configuration matches the current branch name to determine whether to merge
all git branch lockfile files. By default, you need to manually pass the
--merge-git-branch-lockfiles command line parameter. This configuration allows
this process to be automatically completed.
예를 들어:
mergeGitBranchLockfilesBranchPattern:
- main
- release*
!를 사용하여 패턴을 제외할 수도 있습니다.
peersSuffixMaxLength#
- 기본값: 1000
- 유형: number
종속성 키에 추가되는 피어 ID 접미사의 lockfile 내 최대 길이입니다. 접미사가 이보다 길면 해시로 대체됩니다.