Use consistent paths

[thewh1teagle]

Currently every time the shell open in PowerShell the PATH contains random entry from fnm.
It causing multiple issues.
Please use consistent PATH maybe inherit it from the node version / commit.

Thanks for this great project!

Related:
#1087
#808
rust-lang/rust-analyzer#17819
rust-lang/rust-analyzer#17807

By the way the example random entry: C:\Users\User\AppData\Local\fnm_multishells\988_1723044589781

A workaround for now:

PowerShell

fnm list
fnm alias default 20.16.0

Remove RC file of fnm by comment it out

code $PROFILE

Add the default fnm alias path to Windows env

C:\Users\User\AppData\Roaming\fnm\aliases\default

[aaronhuggins]

A couple of scripts that help me out, since I wanted to alias nvm to fnm anyway. These even make it possible to run nvm use <version> and have it affect the current node version regardless git bash or cmd or powershell. I just placed these next to where fnm was installed, and made sure that the install dir and the default alias dir are on the path already. The shell script should also work on OSX.

Environment paths

# Windows
%FNM_DIR%\aliases\default
# Linux/Mac
$FNM_DIR/aliases/default

If you want to exclude multishells from being added to the path, pass the output to filter out PATH before evaluating in your shell profile.

# Some shell rc file, such as .bashrc
eval "$(fnm env | sed '/export PATH=/d')

# A powershell profile
fnm env --shell powershell | Select-String '\$env:PATH =' -NotMatch | Out-String | Invoke-Expression

nvm

#!/usr/bin/env sh

if [ "$1" = "use" ] && [ "$2" != "" ]; then
        # The arguments to `use` should come first so that `default` is an alias to the version.
        fnm alias "${@:2}" default
else
        fnm "$@"
fi

nvm.cmd

@echo off
IF "%1"=="use" (GOTO :UseAlias) else (GOTO :Other)

GOTO :End

:UseAlias
IF "%2"=="" (GOTO :Other)
setlocal ENABLEDELAYEDEXPANSION
set "_args=%*"
set "_args=!_args:*%1 =!"
fnm alias %_args% default
endlocal
GOTO :End

:Other
fnm %*
GOTO :End

:End

Of course, I feel like something like this would be better served within the fnm source code, but I don't have dev cycles for that right now.