Here is something I've been meaning to do for a long time.
If you've had Node-RED installed for a while, it can be tricky to know if you are missing some new or changed settings for it. So I've written some small tools to work out if something has changed and if so, what.
Here is a summary from 1 of the tools - showing whether the default settings.js has changed between one version and the previous. Going back to version 3.0.0 (plus a couple of extras):
Found 40 settings file(s), checking each against the previous version:
v4.1.8 (settings-default-v4.1.8.js): [baseline]
v4.1.7 (settings-default-v4.1.7.js): same
v4.1.6 (settings-default-v4.1.6.js): same
v4.1.5 (settings-default-v4.1.5.js): same
v4.1.4 (settings-default-v4.1.4.js): same
v4.1.3 (settings-default-v4.1.3.js): same
v4.1.2 (settings-default-v4.1.2.js): same
v4.1.1 (settings-default-v4.1.1.js): same
v4.1.0 (settings-default-v4.1.0.js): same
v4.0.9 (settings-default-v4.0.9.js): DIFFERENT
v4.0.8 (settings-default-v4.0.8.js): same
v4.0.7 (settings-default-v4.0.7.js): same
v4.0.6 (settings-default-v4.0.6.js): same
v4.0.5 (settings-default-v4.0.5.js): same
v4.0.4 (settings-default-v4.0.4.js): same
v4.0.3 (settings-default-v4.0.3.js): same
v4.0.2 (settings-default-v4.0.2.js): same
v4.0.1 (settings-default-v4.0.1.js): same
v4.0.0 (settings-default-v4.0.0.js): same
v3.1.15 (settings-default-v3.1.15.js): DIFFERENT
v3.1.14 (settings-default-v3.1.14.js): same
v3.1.13 (settings-default-v3.1.13.js): same
v3.1.12 (settings-default-v3.1.12.js): same
v3.1.11 (settings-default-v3.1.11.js): same
v3.1.10 (settings-default-v3.1.10.js): same
v3.1.9 (settings-default-v3.1.9.js): same
v3.1.8 (settings-default-v3.1.8.js): same
v3.1.7 (settings-default-v3.1.7.js): same
v3.1.6 (settings-default-v3.1.6.js): same
v3.1.5 (settings-default-v3.1.5.js): same
v3.1.4 (settings-default-v3.1.4.js): same
v3.1.3 (settings-default-v3.1.3.js): same
v3.1.2 (settings-default-v3.1.2.js): same
v3.1.1 (settings-default-v3.1.1.js): same
v3.1.0 (settings-default-v3.1.0.js): same
v3.0.2 (settings-default-v3.0.2.js): DIFFERENT
v3.0.1 (settings-default-v3.0.1.js): DIFFERENT
v3.0.0 (settings-default-v3.0.0.js): same
v2.2.3 (settings-default-v2.2.3.js): DIFFERENT
v1.3.7 (settings-default-v1.3.7.js): DIFFERENT
The download-settings.from-tags.mjs file does this & it pulls all of the files from GitHub.
There is also a get-and-compare-settings.mjs which compares your installed version against the current latest. It also pulls the default settings.js from your local install AND, it opens vscode with a diff between your installed version and the version you've previously saved. That also runs the comparison of any downloaded files:
Installed node-red version: 4.1.5
Latest node-red version . : 4.1.8
A newer version of node-red is available. Consider updating to the latest version.
Settings file for installed version (4.1.5) exists: settings-default-v4.1.5.js
Found 37 settings file(s), checking each against the previous version:
v4.1.5 (settings-default-v4.1.5.js): [baseline]
v4.1.4 (settings-default-v4.1.4.js): same
v4.1.3 (settings-default-v4.1.3.js): same
v4.1.2 (settings-default-v4.1.2.js): same
v4.1.1 (settings-default-v4.1.1.js): same
v4.1.0 (settings-default-v4.1.0.js): same
v4.0.9 (settings-default-v4.0.9.js): DIFFERENT
...
The part that opens the diff in vscode is actually in a separate module, diff-versions which you can run as a script as well. This lets you diff between any 2 versions.
I think that settings.js is a file avoided by the less confident users of NR amongst us (or it might just be me!). I am of the opinion that any update of NR that flags a difference between the new file and my old one, as long as NR is running OK, it can stay as it is.
So yes, it would be might be good to have a way that we can see these differences at our leisure, rather in the midst of an install.
Maybe I'll just update this thread after new releases. Might be the simplest way.
My alternate installer has a sample enhanced example settings.js file which is why I was particularly interested in looking at this - so that I can keep it current.
Has anyone made a GUI for settings.js?
There is power in them settings, but like most users, almost every time I play with it, I break it.
The point of NodeRed is no or low code automation, seems odd to me that the system comes with a powerful settings file that will easily break if you get any of the syntax wrong...
If I could write code I'd probably not need NodeRed.... Feels like a hangover from a time when NodeRed was really just a handy GUI to an internal IBM automation engine (Which of course it is/was)...
I think there is now a strong argument for settings.js to become part of the UI in the editor. Or perhaps a standalone application, with a very simplified settings.yaml carrying only minimal elements that should not be available from the GUI.
Pete
I'll give it some thought though, it should be possible but I suspect quite complex.
The main reason for keeping it separate is that it contains things that will break Node-RED easily. But perhaps more importantly, it contains security settings that should not necessarily be exposed to flow authors.
Actually I would say the other way round. The settings.js file is actually executable which was a deliberate choice at the time to allow for greater flexibility. It also allows for comments, which a .json file doesn't (yes I know a yaml file can have comments - but if edited via a UI then :shrug:).
So if we were to split them then I would keep all the non-expose stuff in the .js file and only put ui things in .json or .yaml. Downsides of that is that there are now two places to edit things - in two different styles (.js and .json or .yaml) which I think is even more non-friendly than just one place. Also we then have to decide what to expose where - I mean do I really want things like TCP connection timeouts which not exactly a security thing cluttering up the UI ?
Ok, so perhaps it just needs a friendly UI to edit the settings.js file.
One that's not bothered about script syntax and indenting etc...
Certainly many elements should be in the main NR UI like themes, node list order, context settings ect...
I agree that some settings should never be exposed via the main UI, but there is a lot that could be perhaps?
As it happens I have been looking at trying to create a merge tool that will try to merge any new settings into an existing settings file and it's not too bad if you've only made simple changes and the layout is mostly the same - but struggles if things have been moved all over the place - but it does have a diff mode and a dry-run mode. Obviously I'd like to make it part of the default install/upgrade script but I don't think it is quite good enough yet.
downloaded and played around but here's my problem. This wants to merge old and new files and I don't have a copy of the new original unaltered settings.js file, all mine are modified. Any chance you could post a copy of a virgin settings.js file?
Thanks
We absolutely MUST keep the .js file. It is our "safe" entry point for running things before Node-RED gets started. I have a number of things in mine that check memory usage and pass some system variables into Node-RED.
Then of course, we mustn't forget those people who embed Node-RED into an existing or other Node.js app.
@TotallyInformation reread thread and I'm sorry but I just don't get your tools or how to run them. @dceejay seems pretty straightforward so , sorry but that's the direction I went,
Personally, I would be against that. It's just another complexity that brings no benefit to most people. The .js file isn't hard to edit, especially since the comments were expanded.
No worries, I was just reminding people where this thread started - it has somewhat drifted since then
- yet
