Intimates it was the intention to include a per project settings.js (or settings.json - it's inconsistent) but it doesn't seem to be picking that up for me.
Unfortunately, you cannot do that using projects. Projects share the same Node-RED instance including the settings.js file, useDir and installed nodes.
However, it is fairly easy to have multiple Node-RED instances instead. That gives you completely independent settings, nodes, etc.
That will create you a master folder, install node-red into it, create a userDir (data) folder in it, make sure that settings.js exists and creates a package.json file with suitable npm start scripts. It is cross-platform.
The only thing it currently doesn't do is install node.js for you and it doesn't create a systemd script (for auto-running on Linux) since it is cross-platform - one day I hope to add that as well but it is quite complex as it needs to know about user ids.
Once you have used the script twice to create node-red instances in two different master folders, you can change the settings.js to adjust the ports and any other settings you want to.
You can even have different versions of node-red running simultaneously this way - though my script doesn't cater for that itself just now. However, you can just use the script as a guide for doing your own installation.
I always forget that since I long ago stopped using a global install Thanks for the reminder.
Personally, I still find my method better because you get the ability to run different versions & you can back the whole thing up very easily and even move it to a different device because everything is in one place.
Already good with launching separate instances with different settings files.
It's kind of more that there is a bunch of things in a settings thats tied to what I think of as part of the 'project' that would be nice to just roll into the git repo and not have to worry about rolling different bits and pieces out to setup the environment. Bound port is just an example, but also things like httpNodeRoot, httpAdminRoot, adminAuth; settings in particular seem to me that you'd think of as specific to a project, rather than a particular host.
Your helper @totallinformation looks nice I'll definitely have a look at it.
I have a confession actually - that whilst we use git for the kinds of projects we have we often have all sorts of wierd stuff in the environment, I've taken to running our node-red instances inside a VM and just sharing the VMs around the dev team. Just faster for a dev to get up and running. Overhead is MASSIVE compared to just moving around flows.json etc, but who cares on a gigabit network?
There is nothing stopping you adding a settings.js file to your project and telling Node-RED to use it instead of the default one via the -s command line option.
However, if you change the project you'd need to restart Node-RED to point it at the new settings file.
@knolleary Yeah that's what I'm doing currently - and happy to continue to do so.
It's just given that node-red packages can be managed inside node-red... seems strange that settings can't be... Know what I mean? And that thing I googled implied it was at least on the road map - and was looking to see if it was actually implemented, of if there was a demo somewhere.
If not - all good. Very interesting to see the different way people are using the tool!
Thanks for the reminder.