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 to the User Settings panel of Node-RED editor as shown in the following figure.
what would happen if you also set ABC_USER outside of Node-RED ? Which would have precedence ?
It will be referenced before accessing OS environment variable.
So, the precedence is as follows:
Other app use a .env file - should these global variables be stored in a .env file that could also be edited outside of Node-RED (but displayed/edited as per above) - so it could be part of a deployment workflow - or should they just be part of the flow.
(I'm trying to think when / who / how they should be used... at a global level to me it seems more of a deployment level environment - so I may want to set them at deploy time.... though if you set them just internally with the precedence as above then indeed they would be "locked" to the values set - which may also be useful occasionally)
Where would they get stored?
If you want them to be set via the editor, then it has to be via the storage API. The storage API gives two options - either part of the flows or part of the runtime settings.
They cannot be part of the flow.json (as we have no way of storing top-level properties like this). That means they won't be included when the flow is exported from the editor - unlike flow/group env vars.
The 'User Settings' dialog is specific to the user - with values stored in the runtime settings file against that username. But these settings wouldn't be per-user - they are, as you say global. We don't have anything like that currently.
In my current assumption, global environment variables are saved as part of runtime settings file, possibly .config.runtime.json or .config.users.json.
Another possibility is use of new special config node that holds the global variable mappings.
I think it is possible to use .env file instead, but there is a problem that the value of the environment variable is limited to a simple string type.
If they need to be typed then I think they may need a different name... when I think of environment variables then they should always just be simple strings. (and I would vote for them to be held in a .env file - but I can see this would cause issues on systems where you may not have a file system)
Yes. I agree that the name is a confusing.
But, it is currently named as Environment Variable in both OS and Node-RED.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
