feat: global virtual store #8190
Conversation
21d489c to
c288e57
Compare
There was a problem hiding this comment.
Pull Request Overview
Adds support for a global virtual store to centralize package storage and symlink into project node_modules.
- Introduces
enableGlobalVirtualStore&globalVirtualStoreDirflags across resolution, install, and config layers - Updates dependency-graph builders and installers to route packages into a shared
depsdirectory - Adds new utilities (
iterateHashedGraphNodes,iteratePkgsForVirtualStore) and an end-to-end test for the global virtual store
Reviewed Changes
Copilot reviewed 22 out of 22 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| pkg-manager/resolve-dependencies/src/index.ts | Added enableGlobalVirtualStore flag and extended graph logic |
| pkg-manager/resolve-dependencies/src/resolveDependencyTree.ts | Exposed globalVirtualStoreDir in resolve options |
| pkg-manager/headless/src/index.ts | Updated HeadlessOptions and lockfile graph invocation |
| pkg-manager/core/src/install/index.ts | Integrated enableGlobalVirtualStore into prune logic |
| pkg-manager/core/src/install/extendInstallOptions.ts | Defaulted globalVirtualStoreDir when the flag is enabled |
| pkg-manager/core/src/getPeerDependencyIssues.ts | Passed globalVirtualStoreDir into peer dependency resolution |
| pkg-manager/core/test/install/globalVirtualStore.ts | Added integration test for global virtual store |
| packages/calc-dep-state/src/index.ts | Introduced iterateHashedGraphNodes API |
| packages/calc-dep-state/package.json | Added sort-keys dependency |
| deps/graph-builder/… | Adapted lockfileToDepGraph and iterators for global store support |
| config/config/src/types.ts & Config.ts | Exposed CLI flags enable-global-virtual-store and global-virtual-store-dir |
Comments suppressed due to low confidence (2)
pkg-manager/resolve-dependencies/src/index.ts:122
- The
resolveDependenciesoptions includeenableGlobalVirtualStorebut lack a correspondingglobalVirtualStoreDirproperty, which may lead to undefined being passed intoextendGraph. Consider addingglobalVirtualStoreDir?: stringto the options interface.
enableGlobalVirtualStore?: boolean
packages/calc-dep-state/package.json:40
- The dependency version spec
"catalog:"forsort-keysappears malformed and will likely cause installation failures. Verify and correct the version string.
"sort-keys": "catalog:"
pkg-manager/headless/src/index.ts
Outdated
| @@ -142,6 +142,8 @@ export interface HeadlessOptions { | |||
| currentHoistedLocations?: Record<string, string[]> | |||
| lockfileDir: string | |||
| modulesDir?: string | |||
| enableGlobalVirtualStore: boolean | |||
There was a problem hiding this comment.
Declaring enableGlobalVirtualStore as a required boolean may break existing consumers. Consider making this field optional (enableGlobalVirtualStore?: boolean) to maintain backward compatibility.
Copilot uses AI. Check for mistakes.
| @@ -19,6 +19,7 @@ export const types = Object.assign({ | |||
| 'disallow-workspace-cycles': Boolean, | |||
| 'enable-modules-dir': Boolean, | |||
| 'enable-pre-post-scripts': Boolean, | |||
| 'enable-global-virtual-store': Boolean, | |||
There was a problem hiding this comment.
[nitpick] The new enable-global-virtual-store and global-virtual-store-dir config options need documentation in the CLI reference or README to guide users on their usage.
Copilot uses AI. Check for mistakes.
|
I am not sure yet how this global virtual store will be cleaned. Probably we can do this in a later PR. Probably we could record the locations of all projects using the given global virtual store. The easiest way to record them would be probably to create symlinks to these projects. We'd have a directory with symlinks (e.g. in Once we have the locations of projects that are using the global virtual store, we can recursively resolve all symlink dependencies of all projects. When that's done, we'll have the list of all dependencies currently referenced. All unreferenced dependencies can be removed. |
|
I'd like to check what's the consequence of this (since the linked issue is very old and contains lots of comments that I felt could be outdated)? My understanding that this PR adds an opt-in option to having the PNPM 'virtual store' instead of located at workspace (usually repo root), makes it located at a global location. My questions are:
Thanks~ |
Installation will be much faster during local development.
This doesn't change how
No, the hoisting will not be global. The hoisting remains local to the project. |
This is an addition to #8190. The global virtual store isn't a good choice for CI. So, we disable it even if the setting sets `enableGlobalVirtualStore` to `true`.
close #1001