Global Environment Variable

[HiroyasuNishiyama]

The current Node-Red allows environment variables to be defined for Subflow, Group, and Tab.
However, in some cases, we may want to specify environment variables that are effective for multiple tabs and settings of configuration nodes that do not belong to a tab.

Proposal

To solve the above problem, I would like to propose adding a feature to define global environment variables in Node-RED editor as shown in the following figure.

Implementation

Editor UI

This proposal proposes adding an environment variable definition interface to the User Settings tab of Settings menu. Another idea is to implement it as a top-level menu item instead of being part of User Settings.
The definition interface should be a simple variable definition interface similar to tab and group.

Order of Environment Variable Access

With this proposal, the list of environment variables accessible from Node-RED nodes is:

1. OS-level environment variable,
2. Global environment variable,
3. Tab environment variable,
4. Group environment variable,
5. Subflow environment variable.

Their access order for normal node is defined as follows:

#4 or #5 (enclosing one first)  → #3 → #2 → #1

and access order for global configuration node is defined as follows:

#2 → #1

Storing Variable Definitions

The following two methods can be considered as a means of saving the global environment variables.

1. save variable mappings as properties of a new special configuration node,
2. save variable mappings as part of the runtime configuration file.

This proposal prefer (1) because it has the advantage of exporting configuration files in JSON format that is similar to the current format. Also, global configuration information other than environment variables can be exported using new configuration node. On the other hand, introducing the new configuration node introduces compatibility issues (unknown node) with previous version of Node-RED. It seems that this compatibility issue can be addressed by having installable nodes for previous version of Node-RED, as was the case with Junction node.

global-config configuration node

Introduces new global-config configuration node in order to hold mapping information of global environment variables. It will have the following properties:

name	description
env	array of { name: <name>: value: <value>, type: <type> }

When importing a global-config node, its contents are merged with the existing configuration. If a variable with the same name exists, its value will be overwritten.

[dceejay]

if using the global-config node approach how do we ensure that there is only one ? - What happens when you import a flow that has one into another flow ? How are conflicts resolved ?

[HiroyasuNishiyama]

if using the global-config node approach how do we ensure that there is only one ? - What happens when you import a flow that has one into another flow ? How are conflicts resolved ?

Following part is intended to resolve the issue you have mentioned.

"When importing a global-config node, its contents are merged with the existing configuration. If a variable with the same name exists, its value will be overwritten."

Imported definitions are merged into existing configuration. This ensures only one global-config node can exist. And regarding conflicts, if the same entry exists imported one takes precedence.

[dceejay]

Not sure overwriting is always the right answer - eg if copying from dev to prod... but yes - it's a place to start.

[knolleary]

This feature was delivered in Node-RED 3.1