Project mode - information on how setting.js, package.json and depenendencies are handled

[rogerjames99]

Is there any documentation anywhere on how this works. I can see there are;

• A number of hidden files in the node red home directory.

• A package.json file in the individual project directories.

• A package.json file and a settings.js file in the node red home directory.

But how does this play together. Especially how are project specific settings and dependencies handled.

Any help, pointers or design documents would be great.

[Andrei]

@rogerjames99

A number of hidden files in the node red home directory.

Split .config.json into separate files

[Andrei]

@rogerjames99

• A package.json file in the individual project directories.
• A package.json file and a settings.js file in the node red home directory.

https://nodered.org/docs/user-guide/projects/

[knolleary]

Hi @rogerjames99

There isn't a singular doc that describes how they all relate, but I'll try to describe it.

I will say up front there are areas here I know we need to improve, so what follows is how it works today.

To begin with, lets ignore projects and focus on the runtime files.

• ~/.node-red/package.json - this lists the npm dependencies currently installed in the runtime - ie. nodes.
• ~/.node-red/settings.js - this is the main runtime settings file. This is the file the runtime loads when it starts to get its configuration.
• ~/.node-red/.config.*.js - there are a number of hidden files where the runtime stores its own internal settings. These are not files the user is ever expected to edit manually

When it comes to the projects feature, a project justs consists of:

• package.json - listing the dependencies of the project.
• the flow/credential files

The package.json file contains some project metadata, such as the names of the flows files. It also lists the dependencies - but the runtime does not use that list to install anything automatically. The Project Settings tab in the editor lets you manage the project's list of dependencies - but that only relates to trying to make sure it reflects the nodes the project is actually using.

A project does not have its own independent settings file.

There are a number of areas to improve here - but we don't have a concrete plan for it yet.

1. Better management of project dependencies.
   At the moment the runtime won't automatically install dependencies when opening a project. The editor will point you at the Project Settings dialog where it will highlight what's missing and let you install them.

   If you add a node to the workspace that come from a module not listed in your dependencies, the editor will highlight this if you open the Project Settings dialog, but it doesn't otherwise do anything to help you keep that list up to date.

2. Project settings file
   One of the concepts around projects is you ought to be able to git clone a project and just run it as a standalone node-red application. For that to work, the project needs a settings file and some other bits and pieces added. I wrote a blog post on what that involves a while ago: Creating a Node-RED deployment pipeline to IBM Cloud · knolleary

   One of the challenges with a project having its own settings file is that many of the settings are not designed to be changed dynamically; they are fixed when the runtime starts. If a project brings its own settings, then there are some hard problems around what to do when switching between active projects in the runtime.

   This is why I think of the project settings file as being more for when the project is deployed as a standalone instance; so you have the runtime settings for when you're developing the project and the project's own settings for when you deploy it.

Having said all of that, I know there are teams using the projects feature in their own way - and have other ideas for how this can all be improved. It's certainly a topic I hope we can make progress on this year.

[rogerjames99]

Thanks for the excellent info. That is a lot clearer now.