I'm trying to write scripts that allow me to switch my development environment.
I want to write a script so that I can call it like this:
switchdevA
and inside that script, one of the things it should do is switch to node v16.16.0
inside switchdevA i have the following:
#!/bin/zsh
source ~/.zshrc
nvm use v16.16.0
the output says that I have switched to node v16.16.0, but when I type node -v I get:
v12.22.12
I can fix if i call source switchdevA, but should I do it that way? Other things like java don't seem to require me sourcing. In addition, the installation is lost if I start a new zsh session, ideally it should install for the current session and all future sessions.
What's the best practice around this?
A quick clarification: NVM is a shell function and not an executable.
You've correctly identified that source switchdevA will work properly, and that it is different from other version managers.
One solution is to keep your script as is, and create an additional shell alias that will run source scriptname (e.g. alias switchdevA='source switchdevA').
Unfortunately, for your other request to keep the current Node version in all future shell sessions, that can’t be achieved unless you have some persistence added in. For example, a simple file named ~/.lastnode. Then, in your ~/.zshrc, you would have a line nvm use "$(cat ~/.lastnode)" (which comes after the initialization of NVM). Finally, the original script would need to include a line at the bottom to update the last selected Node version: nvm version > ~/.lastnode.
Related
I have a local vscode installed for windows.
Afterwards I setup wsl-2 and use it as my shell.
When I tried to open a file with code using the code filename command, it installed vscode anew instead of using the local windows install.
Installing VS Code Server for x64 (054a9295330880ed74ceaedda236253b4f39a335)
Is there a way to point wsl to use the windows install when triggering it via the code command?
I don't specifically mind using either or, but settings/extensions etc. for one are not used by the other.
By checking with Git Bash where the location of code is when triggering it (type -a code) and comparing it to the ubuntu wsl shell, I came to the conclusion, that it is actually the same install that is being triggered, . I will have to check why some extensions do not seem to "carry over" though.
The code that is being triggered is a script, that behaves differently when being triggered from within WSL.
How about an alias?
# Set alias
alias code2='/mnt/c/Users/Username/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code'
# Open a file now
code2 file.txt
When you work with two projects and one project depends on node v 8 and another one project depends on node v 10 you have to somehow switch between them.
Not convenient way:
This is not convenient because i have to always remember to type nvm use when i've just entered into root of project dir or when i've just opened new terminal session.
So when you are working on some project you can go in to root dir and run nvm use and it'll pick up node version from your .nvmrc and you can work on this project in this terminal session.
The same thing with another project - nvm use and work in this terminal session.
Convenient but not reliable way:
This is not way reliable because not all of devs have nvm exactly here $HOME/.nvm/nvm.sh and i don't like this hardcoding of nvm path because it's looks like some dirty hack.
Follow answers in this thread and get some working way. This means that just for my personal local developing it will work(i've tried this thread and it's not working because of this error and i don't know what it means)
$ source $HOME/.nvm/nvm.sh && nvm use && nodemon ts-node -r
tsconfig-paths/register src/main.ts nvm is not compatible with the
"PREFIX" environment variable: currently set to "/usr/local" Run
unset PREFIX to unset it.
Engines in package.json way
I've tried write "engines": {"node" : "10.14.1"}, in to my package.json but when i've started yarn - node haven't changed to 10.14.1(it's already installed on my laptop)
I don't know any more ways to conveniently and reliably change my node version just running yarn start. Do you know some way? Or may be you know some best practices?
After some time i've reinstalled my OS and i've tried to use ZSH terminal. There is zsh-nvm plugin which check .nvmrc every time you do cd. Convenient. So good so far.
I have no admin rights in my windows machine. Can I install NVM without admin rights? I tried using the environment variable path setup, but its not working in my case.
I have the same need and couldn't find one, so I created one base on another simple nvm:
https://www.npmjs.com/package/#jchip/nvm
Requires powershell 4+ and permission to execute scripts.
(You're talking about https://github.com/coreybutler/nvm-windows right?)
Whether you can install it without admin rights aside, the actual act of switching node versions with it requires them so you're going to have trouble.
Your best bet is to install different versions of node into different paths manually, and then configure your environment variables to point to the right one whenever you need to use it.
eg. prefix your cmd script with PATH=C:\node\v10;%PATH% to have any node or npm calls in that script use whatever node is sitting in v10
try this
create a bat file like below
#cd C:\Users\testuser\AppData\Roaming\nvm
#SET PATH=C:\Users\testuser\AppData\Roaming\nvm\v14.21.1;%PATH%
cd c:\users\testuser\Desktop\Project
#cmd.exe /K
Run bat file and type
code .
It's open with VSCode
go to the terminal and type node and you can see the node version that you set in the bat file.
enter image description here
You can apply any node version as above bat file
If you use Git Bash on Windows, you can add this to your bash.bashrc to switch node versions:
export PATH=/c/path/to/node/dir:$PATH
Then just restart your terminal to pick up the updated PATH.
It will prepend your path with your desired node version. It's the only way I've found to override the installed node version if you don't have admin rights on your machine.
I'm writing a daemon script for Linux Debian, and I'd need to be able to access the $NVM_BIN shell environment variable, or somehow reference the path to the current "default" Node version as set in nvm.
Several of these daemon scripts will be running on the system.
Since all these scripts can share the same Node version, I'd like to reference some variable that gets automatically updated when I install a new version of Node and define it as "default", without having to manually change the Node JS reference in each script.
Is this possible?
Thanks!
I've finally found a way to do it.
The first line of the shell script must be:
#!/bin/bash
(part of the problems I had was related to the fact that my first line was #!/bin/sh instead)
Then, to access nvm variables or commands you must first source them with:
source <your_path>/nvm/nvm.sh
(where <your_path> needs to be replaced with the path to your nvm folder).
Now you can get the path to the node folder in two ways.
1. Through a standard nvm variable
$NVM_BIN
2. Directly "asking" to nvm
NVM_BIN=<your_path>/`nvm version`/bin/
Nice.
When I run node from the command line with no arguments, I enter an interactive shell. If I execute some commands, exit node, and restart node, the up arrow doesn't do anything (I'd like it scroll through my previous commands).
Is there a way I can invoke node interactively such that it will remember my old commands?
You could use rlwrap to store node.js REPL commands in a history file.
First, install rlwrap (done easily with a package manager like apt-get or brew etc).
Then add an alias for node:
alias node='env NODE_NO_READLINE=1 rlwrap node'
I'm on OSX so I add that alias to my ~/.bash_profile file, and would reload my bash_profile file via source ~/.bash_profile.. and I'm good to go!
Hope this helps!
I found a nice little project, which solves the problem:
https://www.npmjs.org/package/repl.history
install using npm (npm install -g repl.history)
and run repl.history on the command line.
io.js 2.0 includes support for persistent REPL history.
env NODE_REPL_HISTORY_FILE=$HOME/.node_history iojs
The maximum length of the history can be set with NODE_REPL_HISTORY_SIZE, which defaults to 1000.
In io.js 3.0+, REPL history is enabled by default and NODE_REPL_HISTORY_FILE is deprecated in favor of NODE_REPL_HISTORY (default: ~/.node_repl_history).
Node supports this natively.
When in node REPL just issue the following command to save the history:
$> .save ./file/to/save.js
Reference: Commands and Special Keys
As well check file .node_repl_history in user home directory.
I like the combination of both dreampulse's and badsyntax's answers. With repl.history, plus an addition to my .bash_profile I get the behavior I expect, which is command history and syntax highlighting in the node interactive shell, but bypassing repl when called with arguments (to run a script).
npm install -g repl.history
Then edit your ~/.bash_profile, adding:
function node(){
if test "$#" -lt 1; then repl.history
else env node $#; fi; }
Now restart your shell or run . ~/.bash_profile and you're good to go.
Now running
$ node
will open the repl.history nodejs interactive shell, and
$ node program.js [...]
will run program.js with node as expected.