Ok, I give up.. I've had people saying there's a problem with "the script" and Node-Red. Turns out NPN 8 can be an issue (my working clones use npm 6.41) - so I used "the script" myself and sure enough... I even manually updated Node and used Dave CJ's script to updsate/upgrade Node-Red/Node.. still wiping nodes out. For now I'm advising people to unselect NR from "the script" and do their own thing. Is there a single place where there is definitive advise for RPI - assuming starting with standard RASPBIAN FULL (with or without extra desktop stuff) - how to get fully up to date NR and for example SERIAL NODE I2c and SQLITE nodes... I think those 3 are also part of the problem along with Node 8 which has a habit of appearing during upgrades.
If someone can advise I'll redo that section of "the script" to incorporate DaveCJ's script and whatever else is needed. Until Node 8, the only (easily resolved issue used to be the serial node but now I've just lot all extra nodes again. There has to be a better way.
I don't see where you have said exactly what the problem with the standard script is, apart from "still siping nodes out" which I don't understand. Or is it the versions of the some particular nodes that is the problem?
Simple early morning spelling errors Colin - now corrected. For the last few months I've had the odd persion griping about issues with "the script" - see https://tech.scargill.net for more. In all cases it is Raspberry Pi owners and Node-Red - usually where serial, i2c and/or sqlite are involved. I just took what seemed like a working setup, tried to add (in the home/pi/.node-red directory) npm install better-sqlite3 - I stopped Node-Red, did the install, started Node-Red and a ton of node had disappeared. Note - I have a clone Rasapbian setup from a couple of months ago, maybe 3 - which will update/upgrade no problem. It is using npm 6.41 and upgrades just work.
You say "turns out NPN 8 can be an issue" ... npm is only at 6.4.1 (or 6.5 maybe). So do you mean node 8 ? If so the main issue tends to be going from node 4 or 6 to 8 where the nodes you mention all have a binary component and that needs to be rebuilt using npm rebuild in the ~/.node-red directory where any of your extra nodes are.
You then mention better-sqlite3 - this is not used by any of the Node-RED nodes (that you mention so far) - so hopefully you are installing this elsewhere in your directory tree as (given the name) it may well clash with the sqlite3 that node-red-node-sqlite installs.
Note: as mentioned elsewhere when installing this node (using npm i --unsafe-perm node-red-node-sqlite) it can take 20-30 mins to recompile all the binaries.
(PS - actually I was looking at that better-sqlite3 library as a possible "upgrade" to the node - but that's a different thought/thread)
The other issue you might get with later npm (though I thought it was from version 5.x on) is that any nodes that are not mentioned in package.json are silently removed. So if they were installed with an earlier version, and --save was not specified, then an upgrade of npm will remove those nodes. Not very user friendly of npm. --save is now the default, from command line or NR palette manager, so this should be a one off situation.
Out now dropping off kids.. good grief you could be my saviour... If so what a STUPID default. I will test later today for sure, thank heavens for backups.
As usual – I’m getting confused between the two… on my working kit I have node 8. 14.0 and NPM 6.4.1 – does that clarify?
I keep forgetting about the –unsafe-perm… thanks for that. And Colin in here has suggested I need to ensure I use npm –save. Of course in an ideal world we should be doing the lot in Node Red Manage Palette… ok, I’ll make changes to see if I can crack this. With NPM 6.4.1
These are not the only problems with newer versions of npm.
I note that now, npm has a tendency to override the version specification you might have put in manually to your package.json file. So that maybe you thought you would get all new updates (e.g. "*") but installing via npm changes the spec to a more specific version string. Annoying.
I think the fact that you npm install <the package> (with the implicit --save) that npm considers that you want it to put what it thinks best into package.json. If you manually put it into package.json then you can just run npm install
and it will install anything that is not installed, according the spec in package.json, and will not change that file. There is likely a --nosave option or similar that you could use instead though I haven't looked it up.
I had an issue with an 'up to date' installation of Node-Red in that some modules did not like nodejs above V8. The best solution I have found is to install n.
npm i -g --unsafe-perm n
You can then select whatever version of nodejs you need and Node-Red just uses it. Unfortunately you can't have more than one version of nodejs at once, but it works remarkably well.
I believe the intention is to raise that to 10 at some point in the not too distant future. For any nodes you find that are not compatible with node 10 it would be a good idea to raise an issue for the node. @borpin Can you tell us examples of ones you have problems with?
Agreed. Node v8 did deprecate quite a few things that have now finally been removed in v10. So going to v10 does seem to break more things. What in particular are you seeing ? As Colin suggests we should try to get them updated if possible, though they are often outside of our control
