-
Notifications
You must be signed in to change notification settings - Fork 549
docs: rename virtual store to dependency graph store #683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
If approved, we can add new options with new names and remove the old names in pnpm v11. |
I'm sure there's a bit of context to the rename that I'm not aware of yet. Without that, I think I kind of like the existing "virtual store" name. It's relatively short and everyone currently knows what it means. While "dependency graph store" might be more accurate, it's longer and less unique. For example, in macOS, the bottom app bar is called a "Dock". While that's not the perfect name, it's short and everyone is familiar with it. I tend to like short unique names, even if they aren't perfect descriptors. You could imagine an alternate universe where the macOS dock was called "Bottom Application Launcher Bar". |
The virtual store was kind of an internal thing up until now. I don't remember how I came up with this name. I think maybe I borrowed it from Yarn, which has virtual packages. Now with the global virtual store feature this store will become more complex and I was wondering if the name of this store should more closely reflect the nature of it. Virtual store is very generic while dependency graph store is reflecting what this store contains. Of course, it can be named anything as long as the docs explain what it does. |
That all makes sense. Appreciate the explanation above. It makes sense that the "global virtual store" is prompting a rename.
To suggest one more name, how do you feel about isolated store? I believe the isolated terminology came out of the NPM RFC for Isolated Mode, which you helped on. I know we've since adopted this terminology in several places like our The current "global virtual store" would then be called "central isolated store". I tend to like the "central" naming over "global" since global has somewhat negative connotation in programming. Thanks for opening a discussion on this by the way. If that idea above doesn't make sense, feel free to ignore me. |
I think I would rank "central isolated store" the same as "global virtual store". ChatGPT really doesn't like the "central isolated store" name and says it will confuse users as they could think it is per-project and central isolated store is an oxymoron. I am not sure I agree but it did suggest an improved version: hash-isolated graph store (HIGS). HIGS sounds not bad. |
I could see the point around this name being an oxymoron. To counter a bit though, I think we would rarely refer to it as the "central isolated store". I suspect we would normally call it the "isolated store", and in the case where it matters whether the store is local or shared, we'd refer to the config option:
Do you know the reasoning for the I do still vote to omit the "graph" part since I feel it makes the name longer without adding much meaning? |
When the store is inside a project's node_modules, it is enough to isolate it by |
Gotcha. It makes sense that we'd need to hash the full resolution of a package when the store isn't localized. Appreciate the explanation. My personal feeling is the hashing is an implementation detail that doesn't necessarily need to be part of the name. The important and coolest part of this store is that it enables the semi-strict To clarify, did you want to just call the global variant of the store "hash-isolated graph store"? Would the local variant (e.g. |
The local one also uses hashing for the peer dependency graphs, so it probably doesn't make sense to name it differently |
Gotcha. My vote is still leaning isolated store since I think hash is an implementation detail in both the global and local variants, and graph doesn't add much value to the name, but I'm comfortable with you making the final decision. 🙂 |
No description provided.