Depends how you do your installs Pete. If you use Dave's script, it should do it for you? Not sure as I don't use it.
Personally, I use the Node.js official Debian repo, instructions are on their site.
Are you asking this in the wrong thread? This is about the palette manager issues.
not sure about that Julian. I think there is some critera (like if you are on 8 it will upgrade to 12) (not 100% certain)
Last time i updated, i used this article to get v14 then ran Daves install script & it left V14 alone.
1 Like
Thanks Steve, I wasn't totally sure but I thought it upgraded node.js to the current LTS version but I may well be wrong. That is why I don't use those scripts (one reason) - because I can rarely be certain what is happening. I prefer (as a control freak!) to use as close to native tools as possible.
Also why I don't use the various Windows package managers.
1 Like
To upgrade, edit the file /etc/apt/sources.list.d/nodesource.list and change the 10s to 14s. Then sudo apt update && sudo apt full-upgrade, then npm rebuild in the .node-red folder. But why do you want to do that?
[Edit] Also need to re-install node-red
1 Like
To stay current with the latest LTS version.
You only need to do a global and local rebuild.
1 Like
How do you do a global rebuild?
I was asking @scargill why he wanted to do it as he has problems with sqlite.
npm -g rebuild <packagename>
Should work. Though neither SQLlite nor any other node should be installed globally of course.
cd ~/.node-red
npm rebuild
Will rebuild everything in your userDir folder.
So will sudo npm -g rebuild rebuild node-red installed globally? I suppose it should, in which case yes, not necessary to re-install node-red.
Anyway, none of this is anything to do with this thread, so lets try and get back to that.
Should do. I don't install Node-RED globally so I can't test but I don't see why not. That is what the npm rebuild command is for.
@scargill - If you are willing to help ... can you run
npm outdated --parseable | grep -v git | cut -d ":" -f 4 from within the .node-red directory - and report it back here.
This will give a list of nodes that are out of date and the latest versions of them. If this a test machine you could then run
npm i $(npm outdated --parseable | grep -v git | cut -d ":" -f 4 | xargs)
which would just feed that list back into install and force an upgrade to the latest (IE ignore any semantic version restrictions) - and then feedback if they upgraded ok...
and then you could try the nodejs upgrade etc.
@colin, @Steve-Mcl , @TotallyInformation
Where I'm coming from is that we are looking towards Node-RED v2 fairly shortly and at that point we will drop Node8 and 10 support - so the script will have to force people to 14 (we will leave node12 alone)... If we are doing that then we are likely to get a lot of these compile errors unless extra user nodes are at latest level - so I was going to also update those (as above) - before doing any rebuild... but forcing versions up is also not without worries - so wanted opinions, options or other ideas.
I have confirmed that the basic issue here is a regression in node-red. I have updated another system that had a number of nodes showing the update option in the palette manager, from node-red 1.2.3 to 3.2.1 and now only one node is showing an update. Could it be to do with the fact on both systems I have a node installed direct from git, so in package.json I have
"node-red-contrib-owfs": "git://github.com/colinl/node-red-contrib-owfs.git#automatic_retry",
Your suggested command shows them all, and also npm modules I have installed
$ npm outdated --parseable | grep -v git | cut -d ":" -f 4
match@1.2.10
moment@2.29.1
node-red-contrib-queue-gate@1.5.2
node-red-contrib-simple-gate@0.5.0
node-red-node-email@1.11.0
The palette manager has no knowledge of what your package.json says. None at all.
All it knows is the exact version of the module that has been loaded, and the version that is offered by the catalog and then makes a decision based on that and that alone.
We did merge a contribution that was intended to improve the comparison of versions when a version has additional labels (such as 1.2.3-someText). I wonder if that has gone awry in some cases.
I will see if I can reproduce using one of the modules you mention.
On the latest system, of the three nodes due an update queue-gate, simple-gate and email, only queue-gate is offered in palette manager.
On the original system fs-ops, influxdb, msg-resend, and ping are offered but not queue-gate, uibuilder, dashboard and email.
I note that queue gate is offered on the first (1.5.1 to 1.5.2) but not the second (1.5.0 to 1.5.2), so what can be made of that I don't know.
It does appear to be consistent. I installed node-red-contrib-queue-gate@1.5.0 on a third system and it did not offer the update, but if I install 1.5.1 it does offer it.
@Colin thanks - I have reproduced and pushed the fix. It'll be in 1.3.3, although not going to rush that out today.
As I mentioned, we merged a change to support better semver comparisons when a version has extra information in it. There was a bug in that code that meant if the change in version number was >1, then it was overlooked. This is why you were seeing it work with 1.5.1->1.5.2 (because 1->2 is a difference of 1) but not 1.5.0->1.5.2 (0->2 is not, hold on to your hat, a difference of 1).
1 Like
Excellent
It would be good to see this one fixed, assuming it is a bug, as this one does break things. Node-red 1.3.2 MQTT LWT regression
I don't think this should happen without some interaction with the user. Possibly being told what it is going to upgrade and being given the option to say yes or no. Also worth considering whether it should update across major version numbers as that could involve breaking changes. That all gets a bit tedious in a shell script though doesn't it.
As Requested...
npm outdated --parseable | grep -v git | cut -d ":" -f 4
pi@rpi418buster:.node-red:22:34[0]> npm outdated --parseable | grep -v git | cut -d ":" -f 4
@node-red-contrib-themes/midnight-red@1.5.0
dateformat@4.5.1
i2c-bus@5.2.1
moment@2.29.1
node-red-contrib-tasmota@0.9.9
node-red-contrib-ui-time-scheduler@1.10.1
node-red-contrib-virtual-smart-home@1.23.1
node-red-contrib-web-worldmap@2.13.2
node-red-node-email@1.11.0
node-red-node-rbe@0.5.0
node-red-node-sqlite@0.6.0
node-red-node-tail@0.3.1
Is that helpful? Don't assume too much knowledge in replying. I simply followed your instruction and sent you the output.
Its not a test machine but I have clone SDs (for reasons beyond me and nothing to do with this discussion my clone SSD will not boot even after a FULL clone - but the SD clones of my main SSD do work - hence the info above).
I didn't ENTIRELY understand your next paragraph... run npm i etc... so that would do some kind of npm install over the existing 10.x before running your upgrade script?
Happy to try that in daylight on a clone.... over to you Dave
Not sure I'm the best person to ask here as my view is that people should learn how to do things "properly" - by which I (very opinionatedly) mean using native tools.
A lack of understanding is always going to result in confusion for at least a few people when edge cases don't quite work as expected.
Still, I am known to be a bit weird 
I would say that, if you are going to try and update things, you need to tell people what you are going to do and give them a clue and a pointer as to why.
Again, my view is that keeping things up-to-date is generally much safer than "if it ain't broke don't fix it". I've seen far too many painful, late nights sweating over nigh-on impossible upgrades.
So I would say that, in my opinion (for whatever it is worth), yes try to update everything, but keep the user informed with at least links out to more documentation. But I realise that this might be more work than time might permit.
