I spent some time recently testing node red projects feature. And trying to get a proper git repo for node red itself as well as git submodules per project. While the projects are straight forward, I'm not sure what the best approach for the node red program is. Currently running it in docker, so have docker-compose.yml and Dockerfile in the main/root repo together with everything else that comes from the docker bind mount. It works recently well at the moment, but at some cost in terms of configurations and complexity.
For example when running node red (either in prod or locally), the things to click on in the browser affects a multiple files:
- .config.projects.json
- .config.runtime.json
- .config.users.json
Additionally, each user may want to select themes and other settings individually, which affects:
- settings.js
Finally, I got .env file for docker variables and .env.json to be imported in settings.js (since node red doesn't support .env files directly).
So a total of 6 files that must be configured per machine it runs on. My gut reaction was to add all of these to gitignore, then supply example versions for blueprints and even prod versions ready to use. These are later applied in entrypoint.sh depending on some arg to use prod or dev environment.
In the end I'm quite happy with the result, but it takes trial and error to see what files need special handling and this takes time. Having built-in git support for projects and the code itself (flows.json) is nice. But I think having version control and backup of the node-red runtime is important too, as it can contain a lot of details which should be handled in the same way as the code.
I'm still not sure about the exact distinction between package.json in the node red root folder and each individual project folder's package.json. Based on earlier discussion, it sounded like the project package.json has little to no effect and everything goes into main package.json anyway?
Anyone else tried to tame this beast and found some better/smoother solutions?