Support .nvmrc

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?

@chrispat

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:

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.
Allow node-version to be a path to a .nvmrc file.
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).

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.

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}

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.

@damccorm

@damccorm That worked thank you!

I see a couple options here:

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.

Allow node-version to be a path to a .nvmrc file.

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.

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

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

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?

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.

@bryanmacfarlane

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

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

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

Noticed errors weren't being caught when using shell: bash -l {0}

To make sure the GitHub Action fails correctly, make sure to use the -e flag so that bash exists if a command exits with a non-zero status:

shell: bash -e -l {0}

For those looking to copy-paste, my workflow looks like this:

name: Lint code

on:
  push:
    branches: [master, next, next-major, beta, alpha]
  pull_request:
    branches: [master, next, next-major, beta, alpha]

jobs:
  lint-code:
    name: Lint code
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Lint code
        shell: bash -e -l {0}
        run: |
          nvm i
          npm ci
          npm run lint

What I recently develpped to use the package.json engines

jobs:
  build:
    runs-on: ubuntu-latest

    name: node
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Read package.json node and npm engines version
        uses: skjnldsv/read-package-engines-version-actions@v1
        id: package-engines-versions

      - name: Show node version number
        run: echo "Node version is ${{ steps.package-engines-versions.outputs.nodeVersion }}"

      - name: Show npm version number
        run: echo "Npm version is ${{ steps.package-engines-versions.outputs.npmVersion }}"

      - name: Set up node ${{ steps.package-engines-versions.outputs.nodeVersion }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ steps.package-engines-versions.outputs.nodeVersion }}

      - name: Set up npm ${{ steps.package-engines-versions.outputs.npmVersion }}
        run: npm i -g npm@"${{ steps.package-engines-versions.outputs.npmVersion }}"

      - name: Install dependencies & build
        run: |
          npm ci
          npm run build --if-present

      # ... etc

@peaceiris

@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 }}

Refactor the use of actions/setup-node

Refactor the use of actions/setup-node (#545)

Is this fixed with #338?

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

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'

Simplify GitHub Action workflows

get rid of `browniebroke/read-nvmrc-action`, since `actions/setup-nod…

ci: update github actions (#587)

Github actions: use node version from nvmrc

Merge pull request actions#32 from akamai/feature/DEVPOPS-813

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.

Navigation Menu

Repository navigation

Support .nvmrc #32

21 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support .nvmrc #32

Description

Activity

damccorm commented on Aug 16, 2019

dougmoscrop commented on Aug 16, 2019

chingc commented on Aug 28, 2019

damccorm commented on Aug 28, 2019

chingc commented on Aug 28, 2019

travi commented on Sep 28, 2019

peaceiris commented on Oct 9, 2019

chingc commented on Mar 3, 2020

thejoebourneidentity commented on Mar 4, 2020

chrispat commented on Mar 4, 2020

thejoebourneidentity commented on Mar 10, 2020

sarink commented on Apr 2, 2020

bryanmacfarlane commented on Apr 2, 2020

21 remaining items

privatenumber commented on Jun 1, 2021

skjnldsv commented on Jun 17, 2021

gordey4doronin commented on Jul 1, 2021

jameswald commented on Nov 30, 2021

dougmoscrop commented on Nov 30, 2021

mauriciabad commented on Jan 3, 2022

HarelM commented on Nov 10, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions