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
@JimiC that would be great! One thing to note is that we would like to make this completely automated (e.g. it shouldn't rely on hardcoding dubinium to 10.16).
I've done a small bit of digging here, here are some things that might be helpful (apologies if you already know any/all of this):
http://nodejs.org/dist/ is the endpoint we hit right now. It has options for the latest versions of most of these packages.
@damccorm Great!
I had a look at the code and how you are fetching the node version and have an idea on how to tackle this issue. Before I start coding I'll present you my course of actions, in order for everyone to agree on it.
After a lot of thought and searching the docs of popular CI services (Azure Pipelines, AppVeyor, TravisCI, GitLab CI/CD, CircleCi) I come to the conclusion that the following should be supported:
# shorthand of the latest version of node
- node:
alias:
- ' '
- current (?)
- latest (?)
# shorthand of node version 4
- argon:
alias:
- Argon
# shorthand of node version 6
- boron:
alias:
- Boron
# shorthand of node version 8
- carbon:
alias:
- Carbon
# shorthand of node version 10
- dubnium:
alias:
- Dubnium
# shorthand of node version 12
- erbium (?):
alias:
- Erbium
Those with a question mark are cases that I like to discuss with you.
node is used as a shorthand in TravisCI and ' ' in AppVeyor. Should we also support those or are we going with our own shorthand like latest?
Erbium is pending and can't be yet automated. I'm just mentioning it here as a placeholder.
From my POV lts/* should not be a choice, since the GitHub (Azure Pipelines) matrix.node-version property actually executes an iteration of the values specified, passing a single value of the version each time to create an instance. lts/* resolves to multiple node versions that can't be interpreted into firing up multiple instances.
Similarly lts=dubnium should not be a choice either, simply specifying dubnium should suffice.
I'm not sure if lts should be a choice either. Which node version should lts point to?
I think the idea of lts is that its the current lts. So right now, it would resolve to 10.x, but soon will resolve to 12.x. So lts and current are actually interchangeable here, while latest could resolve to a minor version (e.g. 13.x eventually). As long as we doc what we're doing there I think we'll be fine, the call from our product team based on customer conversations was supporting all 3 of these. I'd stick with these rather than go with a different placeholder, I think its a little more explicit this way.
@JimiC yeah, you're right. I don't think we should resolve shorthands ' ' and node though. Those are pretty non-descriptive, so if you look at it and don't know what's going on it won't help you.
OK. So we will dump the travis and appveyor shorthands and go with our own latest, current and lts ones.
Summarizing:
# shorthand of the latest version of node
# (as of the time of writing it's `12.x`)
- latest:
alias:
- current
# shorthand of the recommended `lts` version of node
# (as of the time of writing it's `10.x`)
- lts
# shorthand of node version 4.x
- argon:
alias:
- Argon
# shorthand of node version 6.x
- boron:
alias:
- Boron
# shorthand of node version 8.x
- carbon:
alias:
- Carbon
# shorthand of node version 10.x
- dubnium:
alias:
- Dubnium
# shorthand of node version 12.x
- erbium:
alias:
- Erbium
Note: As soon as Erbium is included in the index.json then it will be automatically supported.
If I'm not mistaken lts/* returns v14 (which is the maintenance LTS) and v16 (which is the active LTS). Maybe you should elaborate on what exactly you are trying to do.
@JimiC you are mistaken. lts/* returns the latest LTS only. You can use lts/-1 etc, or lts/argon, to target a specific maintenance line, but anything that depends on support dates is not part of nvm - nvm’s aliases do not change with the passage of time, only with the release of new node versions.
@JimiC you are mistaken. lts/* returns the latest LTS only. You can use lts/-1 etc, or lts/argon, to target a specific maintenance line, but anything that depends on support dates is not part of nvm - nvm’s aliases do not change with the passage of time, only with the release of new node versions.
@ljharb Thanks for correcting me. Honestly I never use lts/* in my CI/CD as I like to have the control on what node version I'm targeting.
Sure. I'd like to test in CI against all currently supported major versions of Node.js. And it would be nice if I didn't have to occasionally bump explicitly specified versions. That's all, really.
That's exactly what I wanted, which is what I created this node-LTS-versions for. Give it a try.
Sure. I'd like to test in CI against all currently supported major versions of Node.js. And it would be nice if I didn't have to occasionally bump explicitly specified versions. That's all, really.
That's exactly what I wanted, which is what I created this node-LTS-versions for. Give it a try.
Activity
wesleytodd commentedon Aug 16, 2019
nodejs/package-maintenance#236
For reference, this is the alias list we are working out.
JimiC commentedon Sep 5, 2019
@damccorm Do you mind if I give this a try to provide a PR?
damccorm commentedon Sep 6, 2019
@JimiC that would be great! One thing to note is that we would like to make this completely automated (e.g. it shouldn't rely on hardcoding
dubiniumto10.16).I've done a small bit of digging here, here are some things that might be helpful (apologies if you already know any/all of this):
ltsfields.panva commentedon Sep 6, 2019
this may be useful as a reference for using the dist json file.
JimiC commentedon Sep 6, 2019
@damccorm Great!
I had a look at the code and how you are fetching the
nodeversion and have an idea on how to tackle this issue. Before I start coding I'll present you my course of actions, in order for everyone to agree on it.ljharb commentedon Sep 6, 2019
You may also want to reference how https://github.com/nvm-sh/nvm parses that very tab file to support its LTS aliases.
JimiC commentedon Sep 9, 2019
After a lot of thought and searching the docs of popular CI services (
Azure Pipelines,AppVeyor,TravisCI,GitLab CI/CD,CircleCi) I come to the conclusion that the following should be supported:Those with a question mark are cases that I like to discuss with you.
nodeis used as a shorthand inTravisCIand' 'inAppVeyor. Should we also support those or are we going with our own shorthand likelatest?Erbiumis pending and can't be yet automated. I'm just mentioning it here as a placeholder.From my POV
lts/*should not be a choice, since the GitHub (Azure Pipelines)matrix.node-versionproperty actually executes an iteration of the values specified, passing a single value of the version each time to create an instance.lts/*resolves to multiplenodeversions that can't be interpreted into firing up multiple instances.Similarly
lts=dubniumshould not be a choice either, simply specifyingdubniumshould suffice.I'm not sure if
ltsshould be a choice either. Whichnodeversion shouldltspoint to?damccorm commentedon Sep 9, 2019
This generally looks great. A couple thoughts.
I think the idea of
ltsis that its the currentlts. So right now, it would resolve to10.x, but soon will resolve to12.x. Soltsandcurrentare actually interchangeable here, whilelatestcould resolve to a minor version (e.g.13.xeventually). As long as we doc what we're doing there I think we'll be fine, the call from our product team based on customer conversations was supporting all 3 of these. I'd stick with these rather than go with a different placeholder, I think its a little more explicit this way.Agreed on using
dubiniuminstead oflts=dubinium.Agreed on holding off on
Erbiumfor now.JimiC commentedon Sep 9, 2019
One more clarification. According to https://nodejs.org/en/
lts-> 10.xcurrent-> 12.x which should also be resolved for shorthands' ',nodeandlatestCorrect?
Note: https://nodejs.org/en/about/releases/
ljharb commentedon Sep 9, 2019
Is there a reason not to use nvm, and get all these conventional aliases for free?
JimiC commentedon Sep 9, 2019
If only
nvmfor windows was the same as for*nix, Been wanting to start such a project but time is against me.damccorm commentedon Sep 9, 2019
@JimiC yeah, you're right. I don't think we should resolve shorthands
' 'andnodethough. Those are pretty non-descriptive, so if you look at it and don't know what's going on it won't help you.JimiC commentedon Sep 9, 2019
OK. So we will dump the
travisandappveyorshorthands and go with our ownlatest,currentandltsones.Summarizing:
Note: As soon as
Erbiumis included in theindex.jsonthen it will be automatically supported.JimiC commentedon Sep 9, 2019
Something else that caught my eye while I was experimenting with
jobsis that if you specifymatrix.node-version: ''instrategythesetup-noderesolves it to10.xmainly because of this https://github.com/actions/setup-node/blob/master/action.yml#L10Should this resolve be kept? It's not documented and may create support.
86 remaining items
tooomm commentedon Jun 1, 2022
With #481 you should be able to solve this with
lts/-1.To "test in CI against all currently supported major versions of Node.js", you would use
lts/-1,lts/*andcurrent.mightyiam commentedon Jun 1, 2022
Yes, that should do. I'll keep an eye on that. Thanks, everyone.
JimiC commentedon Jun 1, 2022
If I'm not mistaken
lts/*returnsv14(which is the maintenance LTS) andv16(which is the active LTS). Maybe you should elaborate on what exactly you are trying to do.tooomm commentedon Jun 1, 2022
Not sure. https://github.com/nvm-sh/nvm#long-term-support states:
You can reference LTS versions in aliases and .nvmrc files with the notation 'lts/*' for the latest LTS.dominykas commentedon Jun 1, 2022
@mightyiam you could also try something like https://github.com/pkgjs/action which will automatically construct the test matrix and call setup-node for you.
ljharb commentedon Jun 1, 2022
@JimiC you are mistaken.
lts/*returns the latest LTS only. You can uselts/-1etc, orlts/argon, to target a specific maintenance line, but anything that depends on support dates is not part of nvm - nvm’s aliases do not change with the passage of time, only with the release of new node versions.JimiC commentedon Jun 1, 2022
@ljharb Thanks for correcting me. Honestly I never use
lts/*in my CI/CD as I like to have the control on whatnodeversion I'm targeting.msimerson commentedon Jun 1, 2022
That's exactly what I wanted, which is what I created this node-LTS-versions for. Give it a try.
mightyiam commentedon Jun 2, 2022
That works for me. Thank you. Everyone.
dmitry-shibanov commentedon Jun 7, 2022
Hello everyone. We released a new version of the action with support of lts/-n aliases. The setup-node action supports such syntax.
For now I'm going to close the issue. If you any updates feel free to ping us or create a separate issue.
Bump all non-major dependencies (#7)
Merge pull request actions#26 from akamai/feature/DEVPOPS-775
Merge pull request actions#26 from jsoref/grammar
Update actions/setup-node action to v4 (#56)