I have a large and complicated Node-RED system that uses quite a few contrib nodes, some of which haven't received updates in a long time (camerapi, nut-ups, owfs, to name a few), and I'm worried that such a large jump forward might break some of these, or indeed much my own code. At the same time I don't want to remain stuck on 1.x forever. My system has Node.JS 12.8.3 and the Node-RED update bash script suggests going to Node-RED 2.2.2 as a "safe" option, but the --nodered-version="2.2.2" command line argument seems to be ignored by the script:
$ ./update-nodejs-and-nodered --nodered-version="2.2.2"
...
Node-RED v3.x no longer supports Nodejs 12
You can force an install of node 14, 16 or 18 by using the --node14, --node16 or --node18 parameter.
However doing so may break some nodes that may need re-installing manually.
Generally it is recommended to update all nodes to their latest versions before upgrading.
If you wish to stay on nodejs 12 you can update to the latest Node-RED 1.x or 2.x version by adding
--nodered-version="1.3.7" or --nodered-version="2.2.2" to that install command. If in doubt this is the safer option.
Please backup your installation and flows before upgrading.
Exiting now.
Thanks, that's reassuring! I decided on a different plan though; I saw that the Pi this is running on is a Pi2 v1.1, whereas I do have a spare Pi2 v1.2, so I'm thinking imma go for a hardware upgrade as well; the 20-30% extra performance of the A53 over the A7 will be quite useful - and it can be overclocked for moar. It's also about time I do a complete rebuild from scratch; the image I'm running is six years old, and a lot of things have changed. I just hope my build notes remain usable as a guide...
While I'm at it, I might even jump to a 64-bit distro, though I'm unsure whether that's a good idea? Everything else being equal, would Node-RED perform better or worse on a 64-bit system compared to a 32-bit one? Given the choice, what would you pick?
I suspect you may be right about that - but I'm in the mood for pain today, so I'm going with pre-release Devuan Daedalus 64. What could possibly go wrong!?
First issue encountered: when installing spi-device with npm (required by node-red-contrib-monarco-hat) I get an error from nan
npm ERR! In file included from ../../nan/nan.h:294,
npm ERR! from ../src/getoptions.cc:4:
npm ERR! ../../nan/nan_new.h: In instantiation of ‘typename Nan::imp::Factory<T>::return_t Nan::New(A0) [with T = v8::Uint32; A0 = long unsigned int; typename Nan::imp::Factory<T>::return_t = v8::Local<v8::Uint32>]’:
npm ERR! ../src/getoptions.cc:35:25: required from here
npm ERR! ../../nan/nan_new.h:208:30: error: call of overloaded ‘New(long unsigned int&)’ is ambiguous
npm ERR! 208 | return imp::Factory<T>::New(arg0);
npm ERR! | ~~~~~~~~~~~~~~~~~~~~^~~~~~
npm ERR! In file included from ../../nan/nan_new.h:189,
npm ERR! from ../../nan/nan.h:294,
npm ERR! from ../src/getoptions.cc:4:
npm ERR! ../../nan/nan_implementation_12_inl.h:177:1: note: candidate: ‘static Nan::imp::FactoryBase<v8::Uint32>::return_t Nan::imp::Factory<v8::Uint32>::New(int32_t)’
npm ERR! 177 | Factory<v8::Uint32>::New(int32_t value) {
npm ERR! | ^~~~~~~~~~~~~~~~~~~
npm ERR! ../../nan/nan_implementation_12_inl.h:183:1: note: candidate: ‘static Nan::imp::FactoryBase<v8::Uint32>::return_t Nan::imp::Factory<v8::Uint32>::New(uint32_t)’
npm ERR! 183 | Factory<v8::Uint32>::New(uint32_t value) {
npm ERR! | ^~~~~~~~~~~~~~~~~~~
npm ERR! make: *** [spi.target.mk:119: Release/obj.target/spi/src/getoptions.o] Error 1
This looks like a 32/64-bit problem, but I have no idea what to do about it; searching web & git turns up nothing relevant. All other nodes I need have installed without issue, including
What happens if you install nan yourself? Same issues?
BTW, my recommendation was going to be: install a 2nd instance of nr on the latest version and slowly migrate over everything you can. Leave what you can't migrate on the old version and plan for re-writing those bits when time permits. Since you have a 2nd device, this is even easier. I think I've done that approach 3 times now.
Nono, you misunderstood me, I mean when installing node-red-contrib-monarco-hat it falls over while installing the spi-device dependency; I did not ask for it to be installed myself.
That's exactly what I'm doing, and precisely because I have a second device to do it on. TBH I consider this to be little more than an experiment at this point. If I can make it go; good. If not, at least maybe I've learned something new.
Is this on an Arm A53 system? The error looks to me like it has to do with 32 vs 64 bit int sizes; could it be something to do with the instruction set?
No, Intel. I was just confirming that it is not the nodejs version, which can often give errors similar to yours if the node is not compatible with later nodejs versions.
