-
Notifications
You must be signed in to change notification settings - Fork 245
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
volta install corepack
doesn't provide corepack's yarn
#987
Comments
Hi @gamoutatsumi, unfortunately, I think it's true that Volta isn't compatible with globally installing corepack. Ultimately, both Volta and corepack are looking to solve the same problem: Making a package manager available to you without relying on a specific version being installed. Volta's has special-case handling for the package managers, so when you run |
Given that node is planning to integrate corepack by default, you may want to consider supporting it. |
Yeah, I think we'll need to evaluate how to do a partial passthrough for when Node starts shipping Corepack. We need to do it in a way that won't break down on older Node versions that don't include Corepack. I don't know that we can reasonably support the 3rd-party package version without a significant refactor, however, and once it's included by default the value-add is quite a bit lower. |
Today we use Volta to control versions for both Node and Yarn, but we now plan to use Volta for Node (in dev / prod), and |
I was able to make this work as follows:
|
Looking at how we handle the passthrough behavior, I think that we can make Volta interop with Corepack nicely with a minimal change. It should work as it currently does for Node without Corepack (showing a nice error about missing Yarn), while with Corepack it will delegate to that behavior if you run |
Corepack is bundled with recent node versions. The documentation suggests it's available as an executable just like
It's experimental at the moment, but given Corepack is expected to be core functionality, when installing a compatible version of node should volta shim |
@sirreal Yeah, once we have support for calling the Corepack version of |
IIUC, the only benefit of using corepack's yarn is because corepack looks at the |
@brandonchinn178 Yeah, that definitely would be an intermediate approach to help improve compatibility. There's a bit of design that would need to happen there (we'd definitely love a small RFC!) around how we handle Somewhat related to #282, which tracks the potential for pulling version information from different sources. |
Deprecate |
If we can avoid adding "branded" metadata into package.json, more people can have more freedom wrt their choice of node manager |
Some teams don't like adding metadata for individual developers unique tooling choices :) |
Hi @devinrhode2, that's definitely an option we could investigate. The issue with that is it doesn't support choosing the Node version, which is necessary for Volta. We're certainly sympathetic to teams / projects that don't want to accommodate a myriad of ways to support the different developer tooling. We have another issue #282 focused specifically around supporting other mechanisms for defining the tool versions. The main blocker is there are a lot of edge cases and nuances that would need to be worked out before we can move forward. |
Was just wondering if any more progress had been made on potentially landing this PR?:
This would be my suggestion as well, at least for the aspects that Probably done as an opt-in release of Then after some time as deemed appropriate, a new 'breaking change' release of
I think one simple solution to this part is to not fully deprecate the Another alternative would be to use the Or if you wanted to use a slightly less common, but more versatile standard name, asdf's
I also quite like the suggestion made in this other issue:
And this:
|
Related to the above, I just stumbled upon this repo that supports loading the version from a number of locations, in a specified hierachy. It might be overkill for the needs here, but I figured I would mention it in case it's useful:
|
@0xdevalias I would actually advocate your approach, I like it. Well-defined precedence rules are typical for tools like Volta (see for example Edit: I mean some well-defined precedence rules, not necessarily exactly the set you quoted. I'm not sure we should be consulting the config from every tool in existence. I might stick to just defaulting to standards like corepack and falling back to Volta's specific configs. |
I installed https://github.com/nodejs/corepack.
Normally corepack provide yarn binary, but using volta, yarn is linked to
volta-shim
.Volta has not compatibility for corepack?
The text was updated successfully, but these errors were encountered: