I'm thinking of doing an overhaul of the default install script at the same timeframe as v5. The reason being that at that point v5 will default to using nodejs 24, and that drops support for armv6 (and other) 32 bit platforms - so it seems like a good time to clean up the somewhat bloated script to drop handling for older variants, and reduce the number of possible options, and to stop trying to handle every little niggle.
So what I am proposing to do is to
a) Only install nodejs IF there is none installed... IE. If the user has any version installed we will say if it is suitable - but even if not we will leave it in place. If none found we will try to install nodejs 24 (but see b)
b) If there is no nodejs installed AND we detect an armv6 - then install nodejs v22 instead - but warn the user about EOL next year.
c) If we detect running n or nvm then warn the user but proceed anyway.
d) Then install latest Node-RED (user can optionally select version if required)
e) if at the start of the process we detected Node-RED service was running then auto-restart it.
Hopefully this will keep armv6 users going a little while longer as I'm not yet aware of anything in Node-RED core that relies on nodejs 24 - so hopefully it still run on 22 even if not officially supported. If that changes I will update the script to force latest v4 Node-RED instead.
I just feel it is slightly cleaner if we don't try and take over the ownership of a users nodejs install, and enforce upgrades or cleanups on users - even if in some cases it may mean users have to uninstall or upgrade nodejs themselves first.
But as always - I'm looking for feedback thoughts before I go and jump too far in.
well - I still intend to install it if not there at all - so a clean machine -> running Node-RED is a one liner... but if ANY version of nodejs (and npm) is already installed then we skip that and just install Node-RED
There is always scope ! - currently it just checks for any difference. So yes any ideas on best way to merge files without breaking any existing customisations would be much appreciated.
OK - re settings file... it may be possible to do something like this...
1) backup original to settings.js.bak
2) fetch new settings.js with all the new defaults and new "keys" in
3) patch any "keys" in the new file that have been set differently in the original
4) include any extra lines that have been added to the original.
maybe...
possibly worth a try - but I reserve the right to undo it...
After reinstalling Node-red on a Pi today I ran the recommended diff command, diff -y --suppress-common-lines /usr/lib/node_modules/node-red/settings.js /home/pi/.node-red/settings.js,
which returns 87 lines, mostly functionally identical.
A very simple change seems to be to recommend the -w flag - ignore differences in whitespace diff -y -w --suppress-common-lines /usr/lib/node_modules/node-red/settings.js /home/pi/.node-red/settings.js
gives a much shorter and more helpful output.
However it might be more helpful still to analyse the differences key by key, listing those which may be newer than the existing settings.js and are thus omitted, those which are different from the default, and those which have been uncommented in one or other version of the file.
Do you think this worth doing? What would the best language for the task? I imagine using AWK or Perl but as far as I know neither can handle Json with much grace
I actually got rid of that as it's a bit of a waste of resources. I have a Linux server (and several unused Pi's if I get desperate!). But no, WSL isn't the answer for Windows users really, it just leaves you with another containerised OS to manage.
I really don't think that is feasible to be honest. Though it would be great. The file is too complex. If it were a JSON file it would be different, but as a JS file, there are many things you can do (and some of us, ahem! Do).
Having said that, a somewhat significant change to the structure of the file could make this a lot more feasible. Namely, setting the settings into a variable and then having some code that imports/merges from an external file. Then exporting the merged settings variable. That would work and indeed, I already do part of that in my own settings.
Do you think there might be a circumstance where your customisation deletes or comments out a stanza?
If not, it would be moderately simple to include newly introduced stanzas, helping keep the file at least up to date.
They could of course be included commented out, with explanation.
Actually, if you were to look at my settings.js file, you would find that it is very significantly different to the standard one. That includes some additional processing before and after the settings themselves. The after being a setting based on a previous setting in the file - something you cannot do with the standard file.
I am, of course, trying to point out that if I can do it (and do), others can, and probably have, as well. Currently, your script is very robust, I do believe that trying to add a fragile settings merge to it would make it rather lest robust.
The better answer would be to improve the settings.js file to allow merging of an additional external settings file. Just my opinion though.
Honestly, I can't currently remember whether I remove any standard settings. I think I do but not totally sure. But the fact that I could would make the proposed change fragile and could break the installation.
