fix: .nvmrc version error

[OnkarRuikar]

The current version string is producing following error in fnm tool:

Can't find an installed Node version matching >=18.16.0.
Do you want to install it? answer [y/n]: y
error: The requested version is not installable: >=18.16.0

Looks like nvm and fmn tools need a version string that will lead to exact version to install. So conditions like >= can't be used.

After fix it will look like this:

Can't find an installed Node version matching lts-hydrogen.
Do you want to install it? answer [y/n]: y
Installing Node v18.17.1 (x64)
Using Node for alias lts-hydrogen

Note: this will nag contributors install latest LTS of Hydrogen whenever they are available. Which may be good.

/cc @bsmth @Josh-Cena @sideshowbarker @caugner

[Josh-Cena]

No opinions from me, although it is indeed slightly nonideal if it frequently needs new installs :) I wonder if we can update the nvm setup to make it support semver.

[OnkarRuikar]

I wonder if we can update the nvm setup to make it support semver.

I don't think that is possible:

no, we don’t support that - everything in nvm resolves to one single version.

generally I’d expect everyone in an org to be on the exact same version - not just in a range. Why wouldn’t you want everyone on the latest 18?

[Josh-Cena]

The nvm setup is essentially a custom bash script:

cdnvm() {
    command cd "$@" || return $?
    nvm_path=$(nvm_find_up .nvmrc | tr -d '\n')

    # If there are no .nvmrc file, use the default nvm version
    if [[ ! $nvm_path = *[^[:space:]]* ]]; then

        declare default_version;
        default_version=$(nvm version default);

        # If there is no default version, set it to `node`
        # This will use the latest version on your machine
        if [[ $default_version == "N/A" ]]; then
            nvm alias default node;
            default_version=$(nvm version default);
        fi

        # If the current version is not the default version, set it to use the default version
        if [[ $(nvm current) != "$default_version" ]]; then
            nvm use default;
        fi

    elif [[ -s $nvm_path/.nvmrc && -r $nvm_path/.nvmrc ]]; then
        declare nvm_version
        nvm_version=$(<"$nvm_path"/.nvmrc)

        declare locally_resolved_nvm_version
        # `nvm ls` will check all locally-available versions
        # If there are multiple matching versions, take the latest one
        # Remove the `->` and `*` characters and spaces
        # `locally_resolved_nvm_version` will be `N/A` if no local versions are found
        locally_resolved_nvm_version=$(nvm ls --no-colors "$nvm_version" | tail -1 | tr -d '\->*' | tr -d '[:space:]')

        # If it is not already installed, install it
        # `nvm install` will implicitly use the newly-installed version
        if [[ "$locally_resolved_nvm_version" == "N/A" ]]; then
            nvm install "$nvm_version";
        elif [[ $(nvm current) != "$locally_resolved_nvm_version" ]]; then
            nvm use "$nvm_version";
        fi
    fi
}

Which means it's possible to write our own custom logic that replaces the $(nvm current) != "$locally_resolved_nvm_version" line. Of course it would mean some of us use a different config from everyone else, but that sounds acceptable.

[OnkarRuikar]

Which means it's possible to write our own custom logic that replaces the $(nvm current) != "$locally_resolved_nvm_version" line. Of course it would mean some of us use a different config from everyone else, but that sounds acceptable.

One can also run echo '/.nvmrc' >> .git/info/exclude and use the version they want.
Or run touch .my_nvmrc && echo '/.my_nvmrc' >> .git/info/exclude and update the nvm script like this:

elif [[ $(nvm current) != "$locally_resolved_nvm_version" ]]; then
    nvm use $(cat .my_nvmrc);
fi

Down side is that they'll have to figure out themselves when repo needs newer version of NodeJs.

[sideshowbarker]

As an alternative, I’ve opened mdn/yari#9517.

[bsmth]

Testing locally and works fine 👍🏻

[bsmth]

nonideal if it frequently needs new installs

Hopefully this doesn't change often at all, although we did have issues in other minor versions: mdn/yari#9384

[OnkarRuikar]

nonideal if it frequently needs new installs

Hopefully this doesn't change often at all, although we did have issues in other minor versions: mdn/yari#9384

Using 18.17 because it is the latest version which is >18.16 and it is what being used in yari deployment workflows so it works fine.

[bsmth]

Thanks all, I'm going to merge this one now