@gordey4doronin , could you please also add e2e test. See example: https://github.com/actions/setup-node/blob/main/.github/workflows/versions.yml#L32
I think adding new job lts-syntax with node-version: ["lts/*", "lts/Fermium"] should be enough.

P.S. I believe we also need to update docs but we will take care about it in separate PR since we will rework docs in scope of #272

It seems some mocks are lacking for windows test. Will fix later.

could you please also add e2e test.

Absolutely. Good point. Will add too 👍

• Fixed unit tests for windows (was just a path resolution problem)
• Added e2e tests for lts syntax
• Unfortunately had to remove __tests__/verify-node.sh step from it, since the check script doesn't allow to parse lts syntax. However, I it should be enough to have only the main step, it's running actions/checkout@v2 and verifying lts alias resolution. If it couldn't resolve lts alias - it will fail. Profit.

this is a super great functionality that has been not implemented until now, even this package is used for a lot of maintainers.

@maxim-lobanov @konradpabjan can you merge this, please? 🙏

@gordey4doronin @Kikobeats , Merged PR. I will cut new version later today. Need to merge one more PR before that.

Good to see that it only took you about 2 years to finally implement "basic" functionality. Let's hope we, now, can use this action in our CI/CD.

P.S. Sorry if I sound cynical but 2 years is a loooong time for such a vital CI/CD component.

Thank you everyone that worked on this! Great addition! 🎉 🤗 ❤️

@skjnldsv What you don't know and that's why you reacted with 👎 is that I was the first to submit a PR with the exact same functionality 2 YEARS ago.

@JimiC sorry, I understand your frustration, but I don't see how your message helps anyone nor benefit the community in any sort! 😕

Have a great day! ☀️

@JimiC sorry, I understand your frustration, but I don't see how your message helps anyone nor benefit the community in any sort! 😕

@skjnldsv It's just that when GH actions went live I was so excited about it and one of the first to try it out. So much that I even tried to contribute to the community and the community turned their back on me. So they made me from a GH fan to a GitLab fan.

Have a great day! ☀️

You too. ☮️

@gordey4doronin Can you help me to clarify my understanding? Can I at this point remove the node-version argument from the action setup and it will be able to infer the correct version from my .nvmrc file? If not, why? Would it be possible to add this functionality?

@mrlubos Unfortunately you can't.👇 I wish that too. 🙏

Reading the .nvmrc file is not the goal of this PR.
A separate PR shall be created for that

"Resolving aliases" and "reading version manager file" are two different technical tasks.
They're related to each other from business PoV.
But they're not related from code/implementation PoV.

My goal in the first place was to add LTS aliases resolving.

Now it's possible to use this workaround if you have aliases in your .nvmrc file (which I do).

Reading the .nvmrc file is a standalone task, and was out of scope of my completely voluntarily PR.

For reading the file I personally up-voted #32 and actions/runner#1180. 🙂

Hope that makes sense.

@mrlubos Unfortunately you can't.👇 I wish that too. 🙏

Reading the .nvmrc file is not the goal of this PR.
A separate PR shall be created for that

"Resolving aliases" and "reading version manager file" are two different technical tasks.
They're related to each other from business PoV.
But they're not related from code/implementation PoV.

My goal in the first place was to add LTS aliases resolving.

Now it's possible to use this workaround if you have aliases in your .nvmrc file (which I do).

Reading the .nvmrc file is a standalone task, and was out of scope of my completely voluntarily PR.

For reading the file I personally up-voted #32 and actions/runner#1180. 🙂

Hope that makes sense.

Thanks @gordey4doronin! I checked the issue you linked and what do you know, my vote is already there, too 😃 Have a nice day!