I've been using NVM for Windows to run two versions of Node on my system, the latest version and the LTS version. However, I haven't updated Node since installing NVM. I would like to update both versions to their current iterations (11.5.0 and 10.14.2 at the time of writing), ideally without having to reinstall all of my global packages for each. I know the original NVM has this capability with the --reinstall-packages-from flag, but it doesn't look like there's anything similar in NVM for Windows.
You're right, there's nothing similar in NVM for Windows. If it would be useful for you, you could always request it by opening an issue on the github page.
It sounds like you already know how to install 11.5.0 and 10.14.2, and that once you do, running nvm use 11 or nvm use 10 will automatically select the latest appropriate version (but you'll still have to manually reinstall any global packages).
This might be an opportunity to take stock of global packages, they often cause more trouble than they are worth. (In general, the fewer global packages installed the better.)
It's unsupported by design
https://github.com/coreybutler/nvm-windows/issues/236
NVM4W provides a more minimalistic approach, focusing on node version
management, not npm management. NVM4W leaves workflow customization to
the end user... because a) it's not hard, and b) it's very
opinionated.
The statement "switching node version needs reinstallation of all
packages in most cases" is unsubstantiated. This doesn't mean it's not
true, but there aren't any stats to back this claim. There are plenty
of use cases where this is not the case, such as developing original
modules with forward/backwards compatibility.
Third, automating this process, either forcibly or by default, has a
number of unintended consequences in a Windows environment. See the
Roaming Profiles use case for an example.
Even if this were a non-default optional command, it still strays from
node version management into npm management. This is an entirely
different problem (and a much bigger problem).
Related
Unfortunately, we have projects with different nodejs versions. I am not sure if this is like java where I can have multiple jdks installed(multiple nodejs installed) and each project magically uses the correct version via a config file? Also, most commands in tutorials are not including version numbers when installing tools and libraries like so
npm install -g expo-cli (tool)
npm install #react-navigation/native (library)
Coming from gradle with the gradle wrapper where everyone on the team uses the tools and library versions defined in the build.gradle file, this is odd to me. In the gradle world, everyone on the team uses the same exact version of gradle(gradle itself ensures if one person upgrades it in the repo, everyone gets the upgrade and stays in sync on the same version). Then there is plugins/tools and those versions are defined and then libraries and those versions are defined.
How do I guarantee everyone is using the same npm, node, expo, etc. tools?
How do I guarantee everyone is using the same libraries?
How do I guarantee everyone is using the same typescript?
Ideally, we upgrade any of these in the repo + any fixes to the upgrade so on checkout, developers start using the new tool + new *.tsx files so it is seamless much like in the gradle world. In gradle, I upgrade the
version via a property
versions of plugins/tools
build.gradle files
any source code files
and check that all in as a unit such that any developer that checks out is using all the correct versions together. I want this in react-native for our ios/android mobile project or as close as I can get.
I have hacked things before as in installing 'ant' into the git repo and this worked wonders(even though it is such an ugly hack) and everyone used the tool in the repo instead of the one on their OS. Perhaps there is a way to do that?
A bloated repo with binaries was worth it's weight in gold to prevent version compatibility hell as people upgraded libraries over time. NOT only that we found that tool bugs were easier to track down as we could revert the repo. NOT only that, we could reproduce builds form 1 year ago as the tooling was reverted where todays npm tools can't build the 1 year ago thing due to all the changes. The advantages just kept piling up and up and I can't even remember all of them.
Tooling running from the repo either via bootstrap like gradle wrapper or full blown thing is generally the best option until the full blown thing is really bloated but even then locking it to a hash on another tool repo could be better
Any ideas welcome here to put my team on all the same tooling(works great for people joining the company or team from another project as well to not have to install much).
thanks,
Dean
Typescript and libraries should be taken care of by removing any carets and tildes in your package.json and specifying exact versions.
One low overhead possibility for the rest could be shell scripting and a private package repo. You could host the versions you want to install internally, and get it all through cURLs.
Or you could add some simple scripts in your npm pre-install, for example nvm use 12.2.1 should, through error messages, guide the user to installing nvm and using the proper version.
I'm downgrading node.js from v7.7.4 to v0.10.48 because I'm on a CentOS 6.5 server and apparently v0.10.48 is the latest it can handle. Are there issues with going backwards like this?
It should work
There are no issues in way that it will work just as well as it did when it was the current version.
But...
There will be issues with the compatibility of modules on npm. Many of the modules may not work. That is partially because Node v0.10 uses V8 v3.14 (for comparison the current Node versions use V8 v5.x) so a lot of modern JavaScript syntax doesn't work there.
Syntax
For details of what syntax works and what doesn't see:
http://node.green/
For example you will not be able to use a simple arrow functions:
const add1 = x => x + 1;
or even the const keyword for that matter. You will miss a lot of syntax that we now take for granted even on the frontend. Remember that io.js was forked from Node v0.12 mainly because it used such an outdated version of V8 - and it was literally years ago and was about a newer and much modern version than the one you want to use.
Core API
Also the core modules changed during that time changed a lot - compare:
https://nodejs.org/dist/latest-v0.10.x/docs/api/
https://nodejs.org/dist/latest-v7.x/docs/api/
Modules
Because current versions of Node support newer language syntax and have improved core API, a lot of the modules on npm will not work correctly or at all. Make sure that whatever module you use still supports Node v0.10 or use an old version that did support it. You may need to use shrinkwrap to downgrade a lot of sub-dependencies because even if you use an old version of a module that used to work on Node v0.10, it may still load the latest versions of its dependencies that don't work any more.
Security
Also there will be potential issues with bugs and vulnerabilities that will not get fixed. The v0.10 version manitenance ended on 2016-10-31 and the status of this version is currently: End-of-Life. The oldest version that is still maintained today (as of May, 2017) is 4.x.
See:
https://github.com/nodejs/LTS
Is there a way to run two different node versions using nvm-windows in parallel?
nvm-windows creates a symlink in C:\Program Files\nodejs and when you run nvm use x.x.x it updates the symlink to point to the right version under C:\Users\%user%\AppData\Roaming\nvm\vx.x.x (this is where different node versions getting installed)
When you do run nvm use x.x.x, the active version of node is automatically updated across all open console windows. It also persists between system reboots, so you only need to use nvm when you want to make a change. source
So it is highly improbable you can run two different version in parallel.
Probably a bit late on answering this question, but I came across the issue and thought I'll update it with something I found!
For context, I needed to run different node versions across different terminals on windows, and found that nvm-windows does not support it because of the way it works as per Gabriel's answer on top.
Found this wonderful work on github - https://github.com/davfive/nvm-session and all credits to the creator, for building a simple workaround for this. The steps to get this working are clearly explained in the README of the repository, and helped me solve my problem!
However, I believe it requires you to use git-bash/any such bash-supported terminals on windows to get this working!
Thank you!
I have a machine running FreeBSD and the ports tree is accidentaly updated to one of FreeBSD 8 stable. The problem is that my FreeBSD 8.1 is not configured to use PKG for packages so I cannot update or install packages.
I want to upgrade the machines FreeBSD but get the ports tree in working order before I do that.
It seems the only solution is installing an old 8.1 version of the ports tree, but I cannot find any.
Can someone tell me where to find this?
Would upgrading to the lastest stable version 8 also solve my problem?
As far as the "8.1" tree, you can find that by using svn to checkout ports/tags/RELEASE_8_1_0 instead of ports/head but keep in mind this tree is going to be terribly out dated and have lots of insecure software and many things are not even going to fetch properly any more. This is probably not the way to go.
Instead, you are better off upgrading to 8.1, but that is one of two steps needed to fix your situation. The other step is to switch to pkg(ng). The way to do that is to run pkg2ng. See the handbook section on pkgng for more details. Running pkg2ng is a one time operation and doesn't require rebuilding or re-installing all your ports. Instead this just tells pkg about the existing software so it can manage it.
A beginner's Cygwin question here - I'd like to install a newer version of Cygwin (the latest, which is 1.7.9) on a few Windows 2008 Server boxes which currently have rather an old version (1.5.25). I need to do an offline, silent install, and I'm currently deciding whether to do some sort of manually produced list of changed/added/removed files, or just replace the old install with the new. The install is quite big (80 odd megs), so just doing the differences might make sense here. It looks like there is nothing in the way of registry servering or so on required to install Cygwin -you just copy the files somewhere, add it the the path and you're good to go.
One problem, though, is that looking at what's changed between old and new reveals that some of the files the most recent install has used are actually older versions that what we've already got. Ie cygintl-8.dll, envsubst.exe, gettext.exe. Surely you can't mix and match versions?
I'd appreciate it if a more experienced Cygwin user could reply with a few hints as to the best approach here.
There's always an official config.ini file that lists a recommended version of each package, plus often both newer and older versions than the recommended one. When you do an installation with setup.exe, you can elect to use the bleeding edge versions for some or all of the packages. Perhaps your 1.5.25 version was installed with all the bleeding-edge packages, and the 1.7.9 just accepted the defaults. It's not unlikely that some sets of old/current/new packages hadn't changed between those two cygwin versions.
In general, you can mix and match a lot of things, just as you can on Linux. You can't take an old version of the core cygwin1.dll library and expect new packages to run against it; but not all the packages have to be in lockstep.