Support .nvmrc

[dougmoscrop]

It would be nice if setup-node understood an .nvmrc file (even if it does not use nvm under the hood, the idea is the node-version is just the contents of the file).

If GitHub Actions as a whole could read the contents of a file as part of an expression, I could do something like

uses: setup-node@v1
with:
  node-version: {{ contents(.nvmrc) }}

But I don't know where to log that type of feature request!

Perhaps '.nvmrc' could be used as a special placeholder, so that:

uses: setup-node@v1
with:
  node-version: '.nvmrc'

Instructs this action to read the contents and treat the contents as the desired version?

[damccorm]

If GitHub Actions as a whole could read the contents of a file as part of an expression

I think its probably unlikely we're going to expand our expression parsing to that degree - in general computation isn't supposed to happen there and we want to discourage moving in that direction, and keep that more towards just reading existing variables. Note that you could do something like the following here:

run: nvmrc=$(cat .nvmrc)

uses: setup-node@v1
with:
  node-version: $nvmrc

Perhaps '.nvmrc' could be used as a special placeholder

I'm interested in this option. We're looking at doing something similar in setup-dotnet: actions/setup-dotnet#15. I see a couple options here:

1. If there's a .nvmrc at the root of the repo (or the current working directory) and no node-version specified, automatically use the version in the .nvmrc file. Maybe have a variable that allows you to turn this on or off.
2. Allow node-version to be a path to a .nvmrc file.
3. Don't allow this option.

@chrispat, any thoughts on this one? I think maybe we should establish a pattern here and with setup-dotnet for similar requests (I'm sure node and dotnet aren't the only tools with config files that can specify versions).

[dougmoscrop]

Thanks for the tip* about just using an output, that makes sense and is good enough for me, though the simpler developer experience would be nice.

[chingc]

I think its probably unlikely we're going to expand our expression parsing to that degree - in general computation isn't supposed to happen there and we want to discourage moving in that direction, and keep that more towards just reading existing variables. Note that you could do something like the following here:

run: nvmrc=$(cat .nvmrc)

uses: setup-node@v1
with:
  node-version: $nvmrc

I tried to do this and it seems to be treating the environment variable as a literal instead of getting its value.

Here's the error and my config:

##[error]Unable to find Node version '${NVMRC}' for platform linux and architecture x64.

- name: Read .nvmrc
  run: NVMRC=$(cat .nvmrc)

- name: Use Node.js (.nvmrc)
  uses: actions/setup-node@v1
  with:
    node-version: ${NVMRC}

[damccorm]

Sorry, had a lapse when I wrote this. Try changing your workflow to:

- name: Read .nvmrc
  run: echo "##[set-output name=NVMRC;]$(cat .nvmrc)"
  id: nvm

- name: Use Node.js (.nvmrc)
  uses: actions/setup-node@v1
  with:
    node-version: "${{ steps.nvm.outputs.NVMRC }}"

Env variables are scoped to a given step so they don't automatically carry over, but we can use outputs instead.

[chingc]

@damccorm That worked thank you!

[travi]

I see a couple options here:

1. If there's a .nvmrc at the root of the repo (or the current working directory) and no node-version specified, automatically use the version in the .nvmrc file. Maybe have a variable that allows you to turn this on or off.
2. Allow node-version to be a path to a .nvmrc file.
3. Don't allow this option.

if it's helpful in making the decision, travis-ci has the behavior of 1. and is very often sufficient for my projects. it also has the benefit of removing the need to keep the versions in sync for what is intended for use with local development and the version intended for CI since there is a single source of truth rather than distributing across multiple files.

[peaceiris]

The following also works well.

    - name: Read .nvmrc
      run: echo ::set-output name=NVMRC::$(cat .nvmrc)
      id: nvm

    - name: Setup node
      uses: actions/setup-node@v1
      with:
        node-version: '${{ steps.nvm.outputs.NVMRC }}'

• Setting an output parameter | Workflow commands for GitHub Actions - GitHub Help
• An example on my workflow - peaceiris/actions-gh-pages/.github/workflows/test.yml

[chingc]

Has there been any progress towards natively supporting .nvmrc instead of having to use set-output?

[thejoebourneidentity]

We got the following issue in the virtual environments repo: actions/runner-images#4

What's the latest on the plans to support .nvmrc? Is it on the roadmap?

[chrispat]

I think the action could be updated to support .nvmrc as the default if no version is specified in the node-version parameter. At the moment we do not have anyone we an assign to do that work in the action but it does feel like something we could code review as a community contribution.

[thejoebourneidentity]

I chatted with @bryanmacfarlane about this. I think for now we're going to close this issue, and instead move forward with the recommendation to just add nvm to the image as is requested in the virtual environments repo. actions/runner-images#4

[sarink]

cating an nvmrc file and using that version should be pretty simple, right?

If you're not already using nvm under the hood to install node versions... Why add another dependency to the mix?

In any case

      - name: Read .nvmrc
        id: node_version
        run: echo ::set-output name=NODE_VERSION::$(cat .nvmrc)

      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: ${{ steps.node_version.outputs.NODE_VERSION }}

works, it's just really wordy to have to put it everywhere

[bryanmacfarlane]

Yeah, pretty straight forward and we haven't closed so we'll get to it at some point. Note that in your example above you should add shell: bash to your first run step if you want to ensure it works on windows as well

[schoenwaldnils]

Wait, this is not supported yet? Well, good to know now 🤷🏻‍♂️
I really hope this will be getting implemented soon.

[peaceiris]

Update/Add nvm · Issue #4 · actions/virtual-environments was closed and nvm will be available on Actions runners 🚀

[chingc]

Update/Add nvm · Issue #4 · actions/virtual-environments was closed and nvm will be available on Actions runners 🚀

I'm so happy about this.

[vvo]

Awesome! How can we know once it's deployed and we can remove custom actions we had to support nvm? Thanks 🙏

[gordey4doronin]

@peaceiris commented on 9 Oct 2019

The following also works well.

    - name: Read .nvmrc
      run: echo ::set-output name=NVMRC::$(cat .nvmrc)
      id: nvm

    - name: Setup node
      uses: actions/setup-node@v1
      with:
        node-version: '${{ steps.nvm.outputs.NVMRC }}'

Yet another variation. 👇 I guess no real advantages or disadvantages though.

    - name: Read .nvmrc
      run: echo NVMRC=`cat .nvmrc` >> $GITHUB_ENV

    - name: Setup node
      uses: actions/setup-node@v2
      with:
        node-version: ${{ env.NVMRC }}

[jameswald]

Is this fixed with #338?

[dougmoscrop]

I declare it fixed! I didn't say it, I declared it

[mauriciabad]

If you got here from googling, let me tell you, that the newest and simplest way of reading the .nvmrc file and using it in actions/setup-node is with the node-version-file option:

  - name: Setup node
    uses: actions/setup-node@v3
    with:
      node-version-file: '.nvmrc'

[HarelM]

I recently added this to my action and publishing started failing. I'm still trying to understand if this is the root cause, but I believe that setting node-version-file causes registry-url to be empty, which I'm not sure is the expected behavior.
Let me know if there's a need to open a different issue about it.