-
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
[Idea] Use external sources to resolve version for volta pin node
#959
Comments
Hi, I'm interested in helping this feature move forward — I don't know any Rust though 😞. Is there a way I can help? Maybe research, specification, or a pseudo code implementation? |
Hi @cprecioso, thanks for the offer! This would actually be a great issue to tackle without needing to know Rust. The current roadblock is that we need a rough idea of the proposed change in an RFC that covers the above topics (and any I missed, of which I'm sure there are many). So some research into the existing state of The RFC process happens in the If that's something you're interested in doing, we'd be delighted to have the help! And if you have any other questions feel free to reach out here or on our Discord. |
Understood! I'll find some time this weekend and do a first pass then 😄 |
I would like to see
A project could create both a
The only thing missing from |
@darcyparker I'm not up-to-date with the work on |
@charlespierce - Yes that's right. It is for one specific version. I have never seen anyone specify multiple versions with it. It would be great if you could support it. (I understand why This is a popular way to create it: This repo provides a kind of spec for it. I don't think there is a formal/official specification. But it feels correct to me based on my experience/understanding of the |
@darcyparker Oh that's very good to know, thanks! We've actually had a long-standing issue around using a separate file from |
I may be wrong about
The spec for |
Yeah, I know that |
Hi, just an update that I said I would try to take a look at it, but life is getting in the way, so if anyone is not taking a crack at this waiting for me (I doubt that, but just in case), please do get at it! |
@cprecioso No worries! This actually may also dovetail with the investigation into #983, or at least they both may be solved by the same RFC. |
It would be helpful to even allow for a |
No updates on this? 😢 |
Yeah when working in a team where people might use different tools (volta/nvm/fnm etc) it's kind of a must to be able to use the |
Please support using |
I think adding support for |
Here's a git workaround to temporarily ignore volta's changes to package.json |
Here is something you can add to your config if you are using fish shell and are forced to use function __check_nvmrc --on-variable PWD --description 'check .nvmrc on pwd change and run volta install'
status --is-command-substitution; and return
set -l dir (pwd)
while not test "$dir" = ''
set nvmrc_file "$dir/.nvmrc"
if test -e "$nvmrc_file"
set nodeversion (cat $nvmrc_file)
volta install node@$nodeversion
break
end
set dir (string split -r -m1 / $dir)[1]
end
end |
From a discussion on Discord, along with the multiple questions we've had around using
engines
instead of the customvolta
key inpackage.json
: One possible way to improve interoperability and convenience would be to change how the version is resolved when a user runsvolta pin node
.Currently, it will find the latest LTS Node version and use that. However, we could update that logic to read the
engines
key and find the latest version that fits into that range (possibly the latest LTS that fits, to maintain the existing behavior). We could also look for.nvmrc
or.node-version
files and use those to resolve. We likely wouldn't be able to support everything that is supported by those files, but we could get close and show an informational message about why we couldn't read a version.This would allow users to conveniently pull the value when
engines
(or other sources) were updated, while still maintaining Volta's model that requires a concrete version. It also would still be easy to be more explicit, using thevolta pin node@<version>
syntax, so there wouldn't be any loss of control over the installed version.We'll need to define the precedence order for when there are multiple sources, as well as document well how it works. We'd also need to decide if this counts as a breaking change or not (I would lean towards it being an enhancement, bumping the minor version, not a breaking change, but I'm open to being convinced otherwise).
The text was updated successfully, but these errors were encountered: