Skip to content
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

Support aliasing versions #61

Open
aaronpowell opened this issue Dec 9, 2017 · 5 comments
Open

Support aliasing versions #61

aaronpowell opened this issue Dec 9, 2017 · 5 comments

Comments

@aaronpowell
Copy link
Owner

As part of the work to address #60 and have better alignment with nvm's functionality I want an easy way to alias installed versions, and to use aliases other than latest.

@nschonni
Copy link
Contributor

I looked at something like this before for Appveyor. The main source for this stuff in the index.tab/index.json file https://new.nodejs.org/dist/index.tab https://new.nodejs.org/dist/index.json
That contains the LTS aliases

@ljharb
Copy link

ljharb commented Dec 13, 2017

That handles LTS in nvm for sure; we also have user-provided aliases, and node/stable/iojs.

@aaronpowell
Copy link
Owner Author

Ok, so I quickly put up this issue while driving the other day, now it's time to think about how it'd work:

Install-NodeVersion

For this I'm thinking of allowing you to do:

PS> Install-NodeVersion -Version lts

And support the lts pathing like here so you can do lts/argon to install a specific lts release. I'm not sure what lts/* does though, @ljharb can you elaborate?

Set-NodeVersion

Like Install-NodeVersion it'll allow you to provide lts as a version string.

How the internals work

So this is the tricker part (and this is mostly written for my own benefit when I get to the implementation, ie, when I'm not on holidays 😛), I don't really want to futz with the paths on disk and symlinks in Windows are something I'd like to avoid (also, I'm not sure of the best way to do xplat PowerShell symlinking...) so instead we'll use the settings.json file that the install path is set to as a disctionary of aliases to version numbers, so it'd look like:

{
    "aliases": {
        "lts": "8.7.0",
        "lts/argon": "4.9.0"
    }
}

When you do an install using the lts version it'll update that accordingly.

Question: Should installing 8.6.0 on explicitly also set the lts/Carbon alias (if it doesn't exist or is lower)? That is an lts release but if the user hasn't explicitly requested it to be "known" as an lts release should it care?

New cmdlet

We'll add a new cmdlet, Get-NodeVersionAliases which returns all the aliased versions on the system and their "real" versions.

Feedback welcome.

@ljharb
Copy link

ljharb commented Dec 14, 2017

lts/* means "the latest LTS period" - so when Carbon came out, it started meaning "Carbon" even if the day before it meant "Boron".

@ljharb
Copy link

ljharb commented Dec 14, 2017

As far as setting the aliases; nvm updates the LTS aliases any time it contacts nodejs.org, and it also takes steps to prevent the user from modifying those aliases via nvm alias.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants