You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seems to be a fairly popular alternative to npm and yarn. Apologies if this has already been suggested but I couldn't find an existing issue. It would be great to be able to volta pin pnpm.
Agreed, this is definitely something we’ve discussed on Discord, I’m surprised there wasn’t an issue already either. Thanks!
Reacted by Will Soto, Chris Krycho, Denis Malinochkin, Robert Hall, Clément Nerma, Noel Jacob, Julien Cayzac, Marvin Heilemann, Heb, einSelbst and 25 more
Reacted by Will Soto, Chris Krycho, Denis Malinochkin, Robert Hall, Noel Jacob, einSelbst, Pablo Sáez, Kevin Deng, Andy, xzq and 6 more
Hi @arxpoetica, we would definitely welcome that! Adding support for pnpm—or really any unsupported package manager—is a bit involved, though hopefully not too difficult. There are 3 main areas that need to be updated:
The changes here can mostly be based on what is done for npm, the only caveat I'm aware of is that instead of editing the launcher files, we need to create them (so that the bare command pnpm works as expected).
Reading / writing pnpm settings, contained in the platform, project, and toolchain modules.
The changes here should mostly be adding the pnpm key alongside npm and yarn
Running pnpm through the shim, contained in the run module.
Here the logic should be almost identical to the yarn logic.
That's a very high-level overview of the needed changes, but I'll take a look at write some more this week about any corner cases / difficulties I can predict. I'm also happy to pair on this for a while if that would help.
Reacted by Robert Hall, Heb, Claus Klingberg and xzq
@charlespierce this ended up being something I just haven't had time to get around to yet. It's definitely still on my radar, but if someone feels like giving it a head start (or even attacking totally)...
...I think you'll find it happening more quickly. Sorry for my lack of involvement (re: time).
@charlespierce slightly related to this, has any thought been given to pinning arbitrary dependencies that would useful to have available on the command-line? For example, it might be useful to have mocha or tsc installed and available directly on the command line at a specific version without telling users to volta install it themselves. Another example is something like lerna or rush which are the primary entry-points for repos that are managed by those tools.
Under the hood, maybe something specific happens when pnpm is installed but in some ways it is just another command line tool being managed by Volta.
Just wondering if you consider this out of scope since the documentation for pin has something specifically about this.
Hi @willsoto, are you talking about something like #861? In that issue there's some discussion about the complications, however that is definitely something we'd like to support. Or do you mean a setting in package.json that says "Use Volta to manage running lerna"?
If the latter, there's a couple reasons that's not really in scope for Volta:
Technically speaking, Volta operates with shims in a shell-agnostic way, there's no way for us to shim tools that we don't know about ahead of time (if a user runs lerna and the shell says "Command not found", that never goes through anything Volta controls). Individual shells may have a way to control that behavior, but it's unlikely to be universally applicable across OS and shell combinations.
Philosophically, we decided against creating automatic shims for everything that had been installed, because it caused issues and raised some security concerns (see remove autoshimming #235 for the discussions). We ultimately decided that the end user should have direct control over which tools we do or do not manage, so it would go against that to allow packages to take that control away from the user.
Of course I didn't see #861 when I went looking for existing issues 🤦
After reading through it a couple of times, it does seem like that would also solve my problem, just in a different way.
Or do you mean a setting in package.json that says "Use Volta to manage running lerna"?
Yeah, something like this is what I had in mind:
// package.json{"volta": {"lerna": "2.0.0"}}
I totally understand if this is considered out of scope for Volta, but I thought since pnpm is something that gets installed via npm (I don't think they have an alternative way to download?) then you could really get any tool in this way. I'll subscribe to #861 and see where that goes so I don't clutter this issue up. Thanks
@muuvmuuvsuggested us to document Volta as the preferred tool with pnpm. Unlike Yarn, pnpm currently doesn't have the ability to seamlessly switch between different versions of pnpm. So if Volta was to support pnpm, I think we could just recommend using the pin feature of Volta.
Also, @arcanis might be interested in this discussion, he created corepack
Reacted by GSZS and FreeCoderX
Reacted by Marvin Heilemann, Heb, Noel Jacob and GSZS
@zkochan I took a look at it before our 1.0 release late last year, and it actually was somewhat involved, as our models and abstractions around the package managers aren't as clean as they could be (some room for tech debt cleanup). However, it was mostly straightforward. The main sticking point was around the global package directory: As I recall, there isn't a clean way to redirect both the installation and bin directories to a custom location in pnpm using only environment variables.
Volta does that redirection when installing global packages so that we can sandbox them to a specific Node version, and I recall struggling to get that working. I think I could do it with a command-line flag, but that gets a little tricky if there's already one specified and so I didn't dig in too deeply. There also appeared to be a "layout version" type directory that was always appended, which we would need to take into account, but I think I had worked out how we can handle that on our side.
I determined most of that with some experimentation and poking around the source of pnpm, so if there's something I missed about how to define the global directories, that would be much appreciated!
So in all, I think it's probably a larger task than a $50 bounty, however if someone was interested and wanted to collect that on top of the experience, I'd be more than happy to mentor them through it. Working on Volta is also part of my day-to-day, so if I can get it onto the roadmap that would be the other way.
Is there something we could implement on pnpm's side to simplify the task?
You may set the NPM_CONFIG_GLOBAL_DIR env variable to change the global directory used by pnpm. The global bin directory will currently be selected automatically from one of the directories in PATH. pnpm has to have write access to the directory and the directory should have npm, pnpm, nodejs, or node in the path
Is there something we could implement on pnpm's side to simplify the task?
I don't think so, only because those changes would necessarily be in only newer versions of pnpm, while we would ideally want to support a larger range of versions.
You may set the NPM_CONFIG_GLOBAL_DIR env variable to change the global directory used by pnpm. The global bin directory will currently be selected automatically from one of the directories in PATH. pnpm has to have write access to the directory and the directory should have npm, pnpm, nodejs, or node in the path
Interesting, that is jogging my memory a bit. I think I may have been able to get that to work by modifying the PATH, but I don't recall the specific issues I was hitting any more (and I appear to have failed to write them down anywhere). I don't think any of them were insurmountable, just that they were decent amount of work to fit into everything, taking into account our current model.
Just saying, but I'm already using pnpm with Volta since three months without any problems but would also love to see a "clean" way of implementation for future package managers/binaries so Volta will stay on top of the other managers.
Reacted by Zoltan Kochan, Robert Hall, Noel Jacob, Darek Desu, Claus Klingberg, Ben Stickley, Johannes Hoffmann, Angelo Annunziata, Andy, Kuro Hsu and 1 more
Once you switch to the native pnpm support, you may not remove the isolated old pnpm package by calling the same command because lack of uninstall implementation as of now.
Running which pnpm outside of the project results in /Users/Glenn/Library/pnpm/pnpm.
But running which pnpm from the project results in /Users/Glenn/.volta/bin/pnpm.
My intention is to keep using globally-installed pnpm without volta gets in the way. How can I achieve that back? Thank you 🙏
keep using globally-installed pnpm without volta gets in the way.
@dwiyatci There is nothing VOLTA_FEATURE_PNPM can do, Volta can't deal with pnpm that's not installed with Volta. You want to use pnpm outside of Volta then you may need to remove Volta's pnpm shims from PATH.
The project is fully community driven now. It's ok that you going to avoid this avoid that, your business is your business. However that does not help at all just complaining and pressuring in this thread. Read the source code, know how it work and what is unresolved, and submit PRs to contribute, that is the way! And that's how I did and added the existing pnpm support.
Reacted by Mark Oleson, Cris De la Rivera, Kian Esmaeilpour and Andy
Read the source code, know how it work and what is unresolved, and submit PRs to contribute, that is the way!
Totally agree! However, there's 4 years of lessons learnt and large amounts of lore in this thread that people jumping in aren't tracking. Yes they can read the thread, but then there's also things stuck in brains that we don't have access to (such as why certain decisions were made).
I don't know Rust, and my patience for it is incredibly low 🙁, but in the interest of the community, are people able to brain-dump what we all know about this issue, it's challenges, opportunities, and the decisions made throughout the dev process? Perhaps @willsoto could then add these points to the original post he made?
It's ok that you going to avoid this avoid that, your business is your business.
Fwiw, I did move to moonrepo, but it didn't really feel as nice as Volta, and so I've moved back.
Fwiw, I did move to moonrepo, but it didn't really feel as nice as Volta, and so I've moved back.
They are both great tools. But the reason I chose Proto over Volta is not only because it supports pnpm, but also because of its positive attitude towards fixing issues and the high frequency of updates and patches. It also has an active Discord community and enthusiastic maintainers.
Not gonna make any personal comments about this repo and its maintainers, because it's a great library all the same, and I admire the people who have maintained it for so long.
But for those people who are just reading this thread, I hope you go ahead and try moonrepo/proto.
We definitely don’t take it personally – if another tool works better, by all means go for it! And we’re all painfully aware of how little activity the repo has. Moonrepo and proto has actual direct funding to work on it, so more power to them! Volta does not have any ongoing funding, and indeed has only had a few months of active funding since it got to the “solves all of the primary corporate sponsor’s internal needs” point back in late 2019 (and those couple months of work were for solving another of those internal needs).
This is, alas, an all-too-familiar tradeoff of corporate-sponsored OSS: it is really hard to justify further work on it when it solves the problems folks have in whatever corporate context. Insofar as you see work happening on Volta at all, it’s on our personal time—which, in my case for example, is also competing against family time, other non-software projects 🎼, and hobbies besides my job 🏃🏻♂️🚴🏼♂️!
We are doing what we can even so, but again, we’re not offended if people find the velocity and community engagement of other actively funded tools more to their taste: that’s perfectly reasonable and understandable!
Reacted by Daniel Bayley, chaosmos and Andy
Reacted by Roy, Shahrizan, Mick Dekkers, Andy and Mauro Bieg
However, there's 4 years of lessons learnt and large amounts of lore in this thread that people jumping in aren't tracking ... but then there's also things stuck in brains that we don't have access to (such as why certain decisions were made).
If you are concerned about what's unresolved of pnpm support, I believe #1273 and #1394 should be the place to learn instead of this thread, comments in there will help to understand.
But the reason I chose Proto over Volta is not only because it supports pnpm, but also because of its positive attitude towards fixing issues and the high frequency of updates and patches.
No offense, but taking a YC funded project to be compared with a fully community driven project that has no funding, that makes no sense imho. It's good for projects like moonrepo/proto to receive ongoing and healthy funding, especially for open source projects (and I want to say big thanks to those who have sponsored me last year, that made the current state of pnpm support possible). VC funding is a double-edged sword though, the team have to be under the pressure of generating revenue.
For end users, people take advantage of it if they find something meets their needs. That's definitely reasonable, one however should know the funding problem in OSS has been there for decades...
This does not mean demand a sponsorship. But when you don't have funds to sponsor for things you demand, and if you could implement it then contributing code can be the other way to give back to the community. I spent my personal time to contribute to Volta (when I did #1761 that was 11PM), and I still believe that's the positive thing to the project/community.
Sharing a solution that, so far, worked really well for me.
I ended up using volta strictly as a node version manager, which I still believe is the best option out there, and switched for corepack, the build-in node tool, for managing pnpm. Both tools let you pin a specific node/pnpm version for the project, which is essential for me, especially when working with larger teams.
volta install corepack
corepack enable --install-directory ~/.volta/bin
volta pin node@24 # pins node version in package.json
corepack use pnpm@10 # pins pnpm version in package.json
Activity
charlespierce commentedon May 8, 2020
Agreed, this is definitely something we’ve discussed on Discord, I’m surprised there wasn’t an issue already either. Thanks!
arxpoetica commentedon Jul 13, 2020
What would need to take place for this to happen? Point me to the right place in the code, and I'll see if I can get around to a PR.
charlespierce commentedon Jul 13, 2020
Hi @arxpoetica, we would definitely welcome that! Adding support for
pnpm—or really any unsupported package manager—is a bit involved, though hopefully not too difficult. There are 3 main areas that need to be updated:toolmodule incrates/volta-core(https://github.com/volta-cli/volta/tree/main/crates/volta-core/src/tool)npm, the only caveat I'm aware of is that instead of editing the launcher files, we need to create them (so that the bare commandpnpmworks as expected).pnpmsettings, contained in theplatform,project, andtoolchainmodules.pnpmkey alongsidenpmandyarnpnpmthrough the shim, contained in therunmodule.yarnlogic.That's a very high-level overview of the needed changes, but I'll take a look at write some more this week about any corner cases / difficulties I can predict. I'm also happy to pair on this for a while if that would help.
arxpoetica commentedon Sep 17, 2020
@charlespierce this ended up being something I just haven't had time to get around to yet. It's definitely still on my radar, but if someone feels like giving it a head start (or even attacking totally)...
...I think you'll find it happening more quickly. Sorry for my lack of involvement (re: time).
charlespierce commentedon Sep 17, 2020
@arxpoetica No worries at all, thanks for updating!
willsoto commentedon Oct 28, 2020
@charlespierce slightly related to this, has any thought been given to pinning arbitrary dependencies that would useful to have available on the command-line? For example, it might be useful to have
mochaortscinstalled and available directly on the command line at a specific version without telling users tovolta installit themselves. Another example is something likelernaorrushwhich are the primary entry-points for repos that are managed by those tools.Under the hood, maybe something specific happens when
pnpmis installed but in some ways it is just another command line tool being managed by Volta.Just wondering if you consider this out of scope since the documentation for
pinhas something specifically about this.charlespierce commentedon Oct 28, 2020
Hi @willsoto, are you talking about something like #861? In that issue there's some discussion about the complications, however that is definitely something we'd like to support. Or do you mean a setting in
package.jsonthat says "Use Volta to manage runninglerna"?If the latter, there's a couple reasons that's not really in scope for Volta:
lernaand the shell says "Command not found", that never goes through anything Volta controls). Individual shells may have a way to control that behavior, but it's unlikely to be universally applicable across OS and shell combinations.willsoto commentedon Oct 28, 2020
Of course I didn't see #861 when I went looking for existing issues 🤦
After reading through it a couple of times, it does seem like that would also solve my problem, just in a different way.
Yeah, something like this is what I had in mind:
I totally understand if this is considered out of scope for Volta, but I thought since
pnpmis something that gets installed vianpm(I don't think they have an alternative way to download?) then you could really get any tool in this way. I'll subscribe to #861 and see where that goes so I don't clutter this issue up. Thankszkochan commentedon Feb 16, 2021
@muuvmuuv suggested us to document Volta as the preferred tool with pnpm. Unlike Yarn, pnpm currently doesn't have the ability to seamlessly switch between different versions of pnpm. So if Volta was to support pnpm, I think we could just recommend using the pin feature of Volta.
Also, @arcanis might be interested in this discussion, he created corepack
zkochan commentedon Mar 11, 2021
I think we can offer a $50 bounty from our opencollective funds (if this is enough, I don't know how much work it involves).
charlespierce commentedon Mar 11, 2021
@zkochan I took a look at it before our 1.0 release late last year, and it actually was somewhat involved, as our models and abstractions around the package managers aren't as clean as they could be (some room for tech debt cleanup). However, it was mostly straightforward. The main sticking point was around the global package directory: As I recall, there isn't a clean way to redirect both the installation and
bindirectories to a custom location in pnpm using only environment variables.Volta does that redirection when installing global packages so that we can sandbox them to a specific Node version, and I recall struggling to get that working. I think I could do it with a command-line flag, but that gets a little tricky if there's already one specified and so I didn't dig in too deeply. There also appeared to be a "layout version" type directory that was always appended, which we would need to take into account, but I think I had worked out how we can handle that on our side.
I determined most of that with some experimentation and poking around the source of pnpm, so if there's something I missed about how to define the global directories, that would be much appreciated!
So in all, I think it's probably a larger task than a $50 bounty, however if someone was interested and wanted to collect that on top of the experience, I'd be more than happy to mentor them through it. Working on Volta is also part of my day-to-day, so if I can get it onto the roadmap that would be the other way.
zkochan commentedon Mar 11, 2021
Is there something we could implement on pnpm's side to simplify the task?
You may set the
NPM_CONFIG_GLOBAL_DIRenv variable to change the global directory used by pnpm. The global bin directory will currently be selected automatically from one of the directories in PATH. pnpm has to have write access to the directory and the directory should have npm, pnpm, nodejs, or node in the pathhttps://github.com/pnpm/pnpm/blob/9c41e11b0bfa3f4ece2b7d4d67690496f1c9b9c0/packages/global-bin-dir/src/index.ts#L35-L40
charlespierce commentedon Mar 11, 2021
I don't think so, only because those changes would necessarily be in only newer versions of pnpm, while we would ideally want to support a larger range of versions.
Interesting, that is jogging my memory a bit. I think I may have been able to get that to work by modifying the PATH, but I don't recall the specific issues I was hitting any more (and I appear to have failed to write them down anywhere). I don't think any of them were insurmountable, just that they were decent amount of work to fit into everything, taking into account our current model.
muuvmuuv commentedon Mar 12, 2021
I would add another 30€.
Just saying, but I'm already using pnpm with Volta since three months without any problems but would also love to see a "clean" way of implementation for future package managers/binaries so Volta will stay on top of the other managers.
cjk commentedon May 11, 2021
I'm using pnpm a lot, so I'll wait until proper pnpm-support is available before switching to Volta
46 remaining items
lolmaus commentedon May 29, 2023
I was running into this error:
I resolved it by using this command instead:
dwiyatci commentedon Jan 4, 2024
@chawyehsu Seems like I got into this awkward state in a project where:
But then when I ran:
pnpm, it threw:"Volta error: No pnpm version found in this project.".I've got volta v1.1.1 and
export VOLTA_FEATURE_PNPM=0set in my.zshrc.I've read this bit from https://docs.volta.sh/advanced/pnpm#migrating, but I don't quite get it:
Running
which pnpmoutside of the project results in/Users/Glenn/Library/pnpm/pnpm.But running
which pnpmfrom the project results in/Users/Glenn/.volta/bin/pnpm.My intention is to keep using globally-installed
pnpmwithoutvoltagets in the way. How can I achieve that back? Thank you 🙏chawyehsu commentedon Jan 6, 2024
@dwiyatci There is nothing
VOLTA_FEATURE_PNPMcan do, Volta can't deal with pnpm that's not installed with Volta. You want to use pnpm outside of Volta then you may need to remove Volta's pnpm shims from PATH.dwiyatci commentedon Jan 6, 2024
Thanks for the pointer, @chawyehsu! I did the following and seems like I managed to switch back using global pnpm properly:
pnpmentry from/Users/Glenn/.volta/tools/user/platform.json/Users/Glenn/.volta/bin/pnpmpnpm(globally):curl -fsSL https://get.pnpm.io/install.sh | sh -Have a nice weekend! :)🎉
ShravanSunder commentedon May 10, 2024
i'm also curious about the experimental tag and what's outstanding
chawyehsu commentedon May 10, 2024
The project is fully community driven now. It's ok that you going to avoid this avoid that, your business is your business. However that does not help at all just complaining and pressuring in this thread. Read the source code, know how it work and what is unresolved, and submit PRs to contribute, that is the way! And that's how I did and added the existing pnpm support.
smblee commentedon May 10, 2024
FYI I use https://mise.jdx.dev/ now instead of volta.
BleedingDev commentedon May 10, 2024
And now I switched to Proto. :) Would be good to see some comparison.
https://moonrepo.dev/proto
TheBrenny commentedon Aug 5, 2024
Totally agree! However, there's 4 years of lessons learnt and large amounts of lore in this thread that people jumping in aren't tracking. Yes they can read the thread, but then there's also things stuck in brains that we don't have access to (such as why certain decisions were made).
I don't know Rust, and my patience for it is incredibly low 🙁, but in the interest of the community, are people able to brain-dump what we all know about this issue, it's challenges, opportunities, and the decisions made throughout the dev process? Perhaps @willsoto could then add these points to the original post he made?
Fwiw, I did move to moonrepo, but it didn't really feel as nice as Volta, and so I've moved back.
RoyRao2333 commentedon Aug 5, 2024
They are both great tools. But the reason I chose Proto over Volta is not only because it supports pnpm, but also because of its positive attitude towards fixing issues and the high frequency of updates and patches. It also has an active Discord community and enthusiastic maintainers.
Not gonna make any personal comments about this repo and its maintainers, because it's a great library all the same, and I admire the people who have maintained it for so long.
But for those people who are just reading this thread, I hope you go ahead and try moonrepo/proto.
chriskrycho commentedon Aug 5, 2024
We definitely don’t take it personally – if another tool works better, by all means go for it! And we’re all painfully aware of how little activity the repo has. Moonrepo and proto has actual direct funding to work on it, so more power to them! Volta does not have any ongoing funding, and indeed has only had a few months of active funding since it got to the “solves all of the primary corporate sponsor’s internal needs” point back in late 2019 (and those couple months of work were for solving another of those internal needs).
This is, alas, an all-too-familiar tradeoff of corporate-sponsored OSS: it is really hard to justify further work on it when it solves the problems folks have in whatever corporate context. Insofar as you see work happening on Volta at all, it’s on our personal time—which, in my case for example, is also competing against family time, other non-software projects 🎼, and hobbies besides my job 🏃🏻♂️🚴🏼♂️!
We are doing what we can even so, but again, we’re not offended if people find the velocity and community engagement of other actively funded tools more to their taste: that’s perfectly reasonable and understandable!
chawyehsu commentedon Aug 5, 2024
If you are concerned about what's unresolved of pnpm support, I believe #1273 and #1394 should be the place to learn instead of this thread, comments in there will help to understand.
No offense, but taking a YC funded project to be compared with a fully community driven project that has no funding, that makes no sense imho. It's good for projects like moonrepo/proto to receive ongoing and healthy funding, especially for open source projects (and I want to say big thanks to those who have sponsored me last year, that made the current state of pnpm support possible). VC funding is a double-edged sword though, the team have to be under the pressure of generating revenue.
For end users, people take advantage of it if they find something meets their needs. That's definitely reasonable, one however should know the funding problem in OSS has been there for decades...
This does not mean demand a sponsorship. But when you don't have funds to sponsor for things you demand, and if you could implement it then contributing code can be the other way to give back to the community. I spent my personal time to contribute to Volta (when I did #1761 that was 11PM), and I still believe that's the positive thing to the project/community.
Holy that IS awesome!
Szorcu commentedon Nov 14, 2025
Sharing a solution that, so far, worked really well for me.
I ended up using volta strictly as a node version manager, which I still believe is the best option out there, and switched for corepack, the build-in node tool, for managing pnpm. Both tools let you pin a specific node/pnpm version for the project, which is essential for me, especially when working with larger teams.
For setup, there's a great article that covers that in details (https://www.yanglinzhao.com/til/integrating-corepack-and-volta), but essentially all you need are these few commands:
mb21 commentedon Nov 14, 2025
@Szorcu just be aware that
corepackwill not be shipped with future versions of Node.js anymore. However,pnpm>10.21 will now install the correct Node.js version ifengines.runtimeis in package.json.