Node-RED

Version 3.1 released

2023-09-06T00:00:00+00:00

Node-RED 3.1 is now available to install. If upgrading, please read the upgrade instructions.

This release is a little overdue to say the least. We released the first beta back in February - thinking it would be the only one we did. But one thing lead to another and, four beta releases later, here we are finally with the full release for everyone to enjoy.

These delays have had a knock-on effect to our release plan. We’re going to shift things around a bit, but still plan to have Node-RED 4.0 released in the near future to keep up to date with Node.js versions reaching their end-of-life.

We’ll also get back to more regular maintenance releases to keep things moving.

With all that said, and without our usual accompanying video, lets dig into what 3.1 has to offer. As ever, the Change Log has the full list of changes in this release.

Editor Updates
Runtime Updates
- Individual http middleware for httpStatic routes
What’s next?

Editor Updates

Change notifications on tabs

The tab bar now shows a change icon for any tabs that contain changes. This makes it much easier to find where things have changed in your flows.

A bigger workspace

We have occasionally had requests to make the tab canvas bigger. There was even a discussion around making it infinitely large - allowing a flow to be as large as it needs to be. Whilst that’s a nice idea, for this release we’ve simply increased the size of each tab from 5000x5000 to 8000x8000.

We’d still recommend using tools like Subflows and Link nodes to help organise your flows, but at least this quick change will give you plenty more space to use if you need it.

Locking Flows

You can now lock a flow (tab in the editor) to prevent it from being modified. Whilst locked you cannot edit the nodes, add new nodes, modify the wiring… anything.

Why is that useful? You may have a ‘mission critical’ flow that you want to be super careful not to change by accident. You may want to collaborate on some flows with others, but mark some of them as ‘off limits’.

With this release anyone is able to lock and unlock flows, but it lays the ground work for a possible future where particular users may not have permission to unlock flows - allowing them to only edit the flows they are allowed to.

The options to lock/unlock flows are available in the right-click context menu - as well as a new padlock button in the Info sidebar explorer.

To make this work, we’ve modified how ‘nodes’ are managed inside the editor to prevent them being modified on locked flows. No apis have changed, but it does mean certain calls might fail if they are attempted on a locked flow. This has had a fair amount of testing across all of the core features of the editor, but 3rd party node authors are a creative bunch and it is possible someone is doing something ~~sneaky~~ unexpected with their node implementation that gets tripped up by this. So if you see any odd/inconsistent behaviour with this feature, please do let us know (and definitely have ready any error messages from the browser’s JavaScript console).

Hiding Flows

We added the ability to hide flows a couple releases ago. This was done use the ‘eye’ icon that appeared when you hovered over the tab.

We got plenty of feedback, including our own experience, that it was way too easy to accidentally click that button and make things disappear without realising it.

So for this release we’ve gotten rid of that button on the tab. Flows can still be hidden, but you do so via the context menu option when you right-click on the tab bar. You can still use the eye button in the Info sidebar explorer.

New Group User Experience

Following feedback from the community on what it was like to work with the groups feature in the editor, they have been given a big overhaul in this release.

You can now click on any node, inside or outside of a group, and interact with it directly. No more clicking multiple times to get to a node.

Because of that change, you now move a group by clicking on its border and dragging it. But what if you’ve made the border invisible? It now highlights whenever you mouse over it.

We’ve also made it possible to drag multiple nodes into a group in one go - previously we only supported dragging one node in at a time.

And in response to a particular piece of feedback, if you hold down alt whilst dragging a selection of nodes inside a group, you can drag them out of the group.

Overall, this should make for a much for intuitive user experience.

Group-level scope for the Catch/Status

The Catch/Status nodes could already be configured to handle specific nodes within a flow. They can now also be configured to handle just the nodes in the same group as them (or any nested groups).

This gives you more options for organising your flows and their error handling.

We’ve expanded the usefulness of the Context Menu added in the last release. There are now lots more commonly used options available in the menu, which also provides better options related to what you clicked on to open the menu. This includes right-clicking on the tab bar at the top of the workspace to get flow-specific options.

Adding images to node/flow descriptions

All nodes and flows have a Description tab in their edit dialog. This lets you write docs (using markdown) that gets displayed in the Info sidebar when the thing is selected.

With this release you can now drag images directly into the markdown editor and they will get inlined. This is done by base64 url encoding the image directly into the description property.

Mermaid Diagrams

We’ve also added support for Mermaid diagrams. These are diagrams that can be defined directly in the markdown and then rendered out as images when displaying in the sidebar. GitHub recently added support for them, and I’ve found them to be super-useful when documenting things when plain text isn’t quite enough.

Global Environment Variables

We’ve supported defining environment variables scoped to individual flows, subflows or groups for a while. But the only way to define an environment variable available to all flows was to do it via your settings file. That wasn’t very accessible or portable.

So with this release you can now define global env vars via the User Settings dialog:

Under the covers these get added to your flow as a new core configuration node type. That will mean importing a flow from 3.1 with global env vars into an earlier version of Node-RED will lead to an unrecognised node warning - something to be aware of.

New subflow environment variables

Within a subflow, you can now use NR_SUBFLOW_NAME NR_SUBFLOW_ID and NR_SUBFLOW_PATH to access those properties of the subflow instance node.

These join the existing NR_NODE_*/NR_FLOW_* and NR_GROUP_* equivalents.

Changes to how Environment Variables are evaluated

Environment variables are statically defined values that cannot be changed whilst the flow is running. There were some edge cases to this, such as using a JSONata expression of $now() that would get re-evaluated every time it was referenced.

Because of the need to make JSONata fully asynchronous in the future, we’ve changed how the env var evaluation is done - their values are now all generated when the flows start and not re-evaluated again.

This should not cause any changes in behaviour, unless you were relying on the $now() trick that was not an intentional behaviour.

As nodes can depend on env var values, we’ve also updated the logic around the ‘modified nodes’ and ‘modified flows’ types of deploys. Changing an env var at the flow level will now cause all of the nodes on that flow to be considered modified. This is a bit of a blunt solution for this release and we may refine it to be more selective to only the nodes that reference the changed env var - but that’s for another day.

Linking to Node Help

Every node dialog now has a help button in its footer. This will open the Help sidebar and display the… you guessed it… help for the node.

Deprecating synchronous access to JSONata

This is one for node authors rather than end users.

JSONata 2.0 was recently published and promises a lot of significant performance improvements. However it brings a major breaking change - you can no longer evaluate expressions synchronously. So we can’t upgrade to it quite yet, but we can lay some ground work for it.

Since we introduced JSONata into Node-RED, we’ve provided a set of standard APIs for nodes to use. Notably:

RED.util.evaluateNodeProperty - used to evaluate all sorts of standard types of property
RED.util.evaluateJSONataExpression - used to evaluate a prepared JSONata expression

Both of these functions accept an optional callback parameter which allows them to evaluate asynchronously - however they both also allow synchronous behaviour.

With this release we have deprecated calling evaluateJSONataExpression without a callback argument. By extension, evaluateNodeProperty will require a callback if being used with JSONata.

Using these APIs without a callback will trigger a warning in the log, along with a full stacktrace that will hopefully help identify the node that caused it.

Our intention is to update to JSONata 2.0 in Node-RED 4.0 this summer - so we want to flush out any nodes that need updating.

Improved wiring for horizontally aligned nodes

Following this discussion on the forum, we’ve made some modifications to the wiring layout logic to improve cases where wires loop back on horizontally laid out nodes.

Here is a before/after pair of screenshots:

Runtime Updates

Individual http middleware for httpStatic routes

It is now possible to configure separate middleware functions for different httpStatic configured routes.

See #4229 for the details.

What’s next?

As I mentioned at the start, this release is overdue and has pushed back the existing release plan.

With Node.js 16.x reaching its end-of-life next week, we’ll be moving forward with Node-RED 4.0 in the near future. As it stands, we strongly recommend users to be using Node 18 or 20 by now.

As an open-source project we are reliant on the contribution of the community. We have a strong and vibrant user community, well demonstrated by the activity on the forums. It’s great to see the support the community provides each other.

If you’re interested in contributing to Node-RED, now is a good time to come over and chat with us in either the forum or slack.

2023 Community Survey

2023-02-23T00:00:00+00:00

Update: the results are now available here.

Back in 2019 we published the results of the 2019 Node-RED community survey. The results painted an interesting picture of the Node-RED community. We think it is time to refresh these results so we are running the survey again.

The 2023 survey is similar to the 2019. We’ve made a few tweaks, removed some questions and added some new ones. The goal is to get a better picture of who our uses are, what they do with Node-RED and to make sure we keep the project pointed in the right direction.

The survey will be open until March 31. Of course we would like to get as many respondents as possible. In 2019, we have over 800 individuals respond so hopefully we can meet this number again this year.

Once the survey has been completed, we will publish the results for the entire community to see.

The survey should take less than 10 minutes to complete. Thank you in advance for your feedback.

Update: The survey is now closed.

Version 3.0 released

2022-07-14T00:00:00+00:00

Node-RED 3.0 is now available to install. If upgrading, please read the upgrade instructions.

The Change Log has the full list of changes in this release, but here are the highlights.

Migrating from Node-RED 2.x
Editor Features
Runtime Features
Node updates
What’s next?

Migrating from Node-RED 2.x

Here are the key points you need to know when migrating to Node-RED 3.x.

Node.js 14.x or later required
Internet Explorer no longer supported
Choose if you want to enable the Stopping Flows feature
Choose if you want to disable the Runtime Diagnostics feature
Choose if you want to switch to the Monaco editor (if you haven’t already).

Editor Features

We have (finally) added a right-click context menu in the workspace. This gives you quick access to a lot of built-in actions in the editor and should help users discover more of the features available.

Picking what options should be in the menu hasn’t been a simple task. There are a lot of things that could have been included - so we had to get the right balance between having the right options there and making it too long and hard to find.

Junctions

We have introduced a new special node type called junction that can make it easier to route the wires in a flow.

Unlike the various ‘no-op’ nodes that have been published to the community to help achieve similar results, the Junctions are far more compact and less obtrusive in the flow.

When you hover over a Junction, it expands to show input and output ports. You can move the junction by dragging its body, or add a wire by click/dragging on one of its ports - just as you do with nodes.

Junctions do not appear as regular nodes in the palette or flow outline, but can be added through the quick-add dialog (Ctrl-click in the workspace) or the new Context Menu.

You can also insert a Junction into an existing wire by slicing through it with the mouse by holding alt-shift when dragging across the wire. Note that some OS might use that same combination to move the active window, so this won’t work there. We don’t yet have a way to allow the mouse actions to be customised, so users affected by that would have to use the other methods to add Junctions.

When hovering over a node name in the Debug sidebar, a new tooltip shows the full location of the node. This is useful when working with subflows, making it much easier to identify exactly which node generated the message.

Clicking on any item in the list will reveal it in the workspace.

Continuous Search

When searching for things in the editor, a new toolbar in the workspace provides options to quickly jump between the search results.

We’ve added a pair of new actions to help navigate the results:

core:search-next - shortcut: f
core:search-previous - shortcut: shift-f

We’ve also added some more predefined searches, including the ability to restrict the search to the current flow.

Default node names

The Debug, Function and Link nodes are now given unique default names when they are added to the workspace.

This capability could be added to any node, including contrib nodes, via their onadd function. We chose just this initial set as they were the ones that would most benefit from having a name applied.

A new action has also been added that will apply an appropriate default name to any selected nodes that don’t currently have a name:

core:generate-node-names

Monaco Text Editor

We added the monaco editor component as an alternative to the default ace editor a year ago in the 2.x release. It has proven to be very stable and provides a much richer user experience.

With 3.0, we have switched over to monaco as the default editor. New installs of Node-RED will pickup the change - existing installs will need to update (or remove) the codeEditor entry in their settings file.

The ultimate goal will be to remove ace entirely in the 4.0 release next year.

Remembering cursor position

The editor now tries to restore your cursor position when you reopen a node’s edit dialog. This is super handy with the Function node, amongst others, where you don’t want to have to scroll back to where you were working each time you open the edit dialog.

Accessing previous welcome tours

We introduced the Welcome Tour back in 2.1.0 and it has been updated for each release. With this release, we’ve added a way to access the tours of the previous releases in the Help sidebar:

Runtime Features

Editing stopped flows

We’ve introduced the optional ability to run Node-RED without the flows themselves running. We already had Safe Mode that achieved a similar result, but with this new feature, you can stop and start the flows directly from the editor. The runtime will remember the state of the flows so when Node-RED starts up, the flows will stay in the same started/stopped state.

This feature is not enabled by default. To enable it, you need to add the following to your settings.js file:

runtimeState: {
   enabled: true,
   ui: true
}

With that set, you get a new option in the Deploy menu:

Clicking that option will stop the flows running, but you can continue editing them and deploy changes. Whilst stopped, the Inject/Debug node buttons will be disabled.

When the flows are stopped, the menu shows a start option instead:

Diagnostic Report

We’ve added a new admin endpoint that returns information about the runtime and the system its running on. This can be used to quickly gather information when reporting an issue.

Within the editor you can see the information it returns by running the ‘Show System Info’ action.

We have taken care to ensure this does not return anything sensitive. In some cases it will indicate if a particular setting is set, but not what value it has been set to.

We realise that not everyone will want to have this exposed depending on how they use Node-RED. For that reason, the endpoint can be disabled by adding the following to settings.js:

diagnostics: {
    enabled: false
}

Multiple static folders

The runtime has long-supported the ability to serve a folder of static content as part of its HTTP handling. Useful for providing static resources to webpages and the like.

With this release you can now specify multiple folders to serve from and, more importantly, to specify the http path each folder should be served from.

See #3542 for details on how it can be used.

Node updates

Dynamic Link Call node

We added the Link Call node in Node-RED 2.1. It lets you create a flow that calls out to a Link In node and get a response back. The main limitation was you had to hardcode what Link In node you wanted it to call.

With this release you can now use msg.target to set the name of the Link In node it should call.

Environment Variables in the Template node

The Template node can now access environment variables using the syntax:

My favourite colour is {{env.COLOUR}}.

Debug node message count

The Debug node has a new option to report how many messages it has received in its status output.

Predefined HTTP Request headers

The HTTP Request node now allows you to set request headers in the node’s edit dialog - rather than having to always pass them in as message properties.

What’s next?

As happened with 2.0, we’ve overrun our plan for getting 3.0 released in April. But the series of beta releases we have been doing have really helped improve the overall quality of this release.

The main challenge has always been getting enough time and attention dedicated to keep the release cadence going.

Our next scheduled main release will be 3.1 in late October/November. As ever, we have a healthy backlog of items to keep us busy - but ultimately it depends very much on the feedback from the community.

If you’re interested in contributing to Node-RED, now is a good time to come over and chat with us in either the forum or slack.

Node-Red 2.x is now in maintenance mode - we won’t be added any new features to it, but we will do maintenance releases with fixes as needed. In fact, we’ll have a long overdue 2.2.3 release in the next couple of weeks.

Introducing the Node Scorecard

2022-01-31T00:00:00+00:00

Last year we asked the community what frustrations they were experiencing as both users and creators of 3rd party nodes. One of the common themes was that it was hard to judge the quality of a node just from looking at its page on the Flow Library.

Based on that feedback, we’re now introducing Node Scorecards.

The scorecard provides a summary of a Node across a range of things such as whether it follows our naming guidelines, does it have a valid license applied and does it clash with other packages in the library.

When we first introduced the Flow Library, we chose not to act as gatekeepers to what can be shared, beyond some very basic checks on the nodes. The scorecard doesn’t change that, but it does help start to highlight where a node may need some additional work to meet the recommended best practices.

We’ve been running the tool against new submissions to the Flow Library for a couple months now so there are scorecards for many of the recently updated nodes. You’ll now see a link to ‘View scorecard’ in the sidebar of a node’s page on the library, along with a summary of the scorecard.

Click through gives you a more detailed view of the scorecard - listing out all of the checks made. You can find out more about the purpose of each check by clicking on the i link on the right hand side.

Changing our recommended naming convention

As part of the work to improve the overall quality of the Flow Library, we’re making a change to our naming guidelines for node modules.

Previously, we asked that if a module’s name started with node-red-, that it use node-red-contrib- to distinguish it from modules maintained by the core project.

We now recommend that newly published modules use a scoped name - such as @myScope/node-red-sample. That can be your own user scope, or an organisation scope.

If you use a scoped name, there are no further requirements on the name. You could use @myScope/node-red-sample or just @myScope/sample - although having node-red in the name does help to associate the module with the project.

If you are forking an existing package to provide a fix, you can keep the same name but released under your own scope. But please keep in mind, forking should always be a last resort if the original maintainer is not responsive to your contributions.

We won’t be asking anyone to republish their existing modules under this new naming convention, but the scorecard will flag up any newly added modules that don’t follow this new convention from today.

Node Developers

The tool underlying the scorecard is node-red-dev - a new command-line tool that developers can run locally against their own code to check for any possible issues before publishing to npm. Many of the checks are quick and easy to fix - much better to do so before sharing with the community.

You can run the tool either against a path on your local machine or against a package already published to npm using the appropriate flags, and you’ll get the results in the console

The Future

This is the first step in improving the quality of our node ecosystem, over time we will add more checks to the scorecard. It doesn’t currently examine the code of a node, but that is certainly something that could be explored.

There’s also a lot more that node-red-dev could do for Node Developers beyond the scorecard check. For example, using it to bootstrap development of a new node module, with all of the best practices pre-applied.

If that’s something you’re interested in contributing to, please do come talk to us in the forum.

Version 2.2 released

2022-01-27T00:00:00+00:00

Node-RED 2.2 is now available to install. If upgrading, please read the upgrade instructions.

The Change Log has the full list of changes in this release, but here are the highlights.

Highlights
Node Updates
What’s next?

Highlights

Search History

The main search dialog now keeps a history of your searches. This makes it easy to repeatedly search for the same thing.

Remembering zoom/position

Under the View section of the main settings dialog, there are a pair of options to get the editor to remember the zoom level of the workspace, as well as the scroll position of individual tabs.

This is helpful if you prefer to have the workspace zoomed in - you don’t have to reset it every time you reload the editor.

Aligning nodes

With snap-to-grid enabled, nodes with hidden labels (for example, link nodes) can now be aligned on either their left or right edge. This will make it easier to get everything to line up in the workspace

Detaching nodes

You can now delete a node from the middle of a flow and have the wiring automatically repair itself in the background.

This is done by holding the Ctrl (or Cmd) key when you press delete.

You can also detach a node from the flow without deleting it:

We haven’t assigned a default shortcut for that, but you can assign one yourself in the Keyboard pane of the Settings dialog. The action is called core:detach-selected-nodes.

Selecting multiple wires

You can also select multiple wires by ctrl-clicking on them.

When you select multiple nodes, we also highlight any wires between them. This can make it easier to follow a flow once you have selected it.

Slicing wires

We’ve added the ability to remove wires by slicing through them. You do this by holding the ctrl (or cmd) key, then dragging the mouse with the right-hand button pressed:

Subflow Output labels

If you have set output labels for a subflow template (via the Appearance tab of its edit dialog), the editor will now display those labels whilst you are editing the subflow template.

Predefined Environment Variables

We have added a number of predefined Environment Variables that provide access to information about the node, group and flow at the point they are evaluated.

NR_NODE_ID - the ID of the node
NR_NODE_NAME - the Name of the node
NR_NODE_PATH - the Path of the node - this is a new concept that we’ll explain below.
NR_GROUP_ID - the ID of the containing group
NR_GROUP_NAME - the Name of the containing group
NR_FLOW_ID - the ID of the flow the node is on
NR_FLOW_NAME - the Name of the flow the node is on

The guide for using Environment Variables in your flow is available here.

For example, in a Function node, you can do:

const functionName = env.get("NR_NODE_NAME")
const flowName = env.get("NR_FLOW_NAME")
msg.payload = `I was sent by Function '${functionName}', on flow '${flowName}'`
return msg

Node Paths

This is a new internal property of Nodes we’ve added that helps identify where exactly any node is within the overall flows.

The following may sound a bit abstract, and it’s something most users can skip over. But it can be useful when creating your own subflow modules with custom logging messages inside.

If a NodeA is on Flow1, it will have a path of Flow1/NodeA.

That isn’t very interesting, but it gets more interesting when dealing with subflows and, in particular, nested subflows.

When we create an instance of a subflow, all of the nodes in the subflow are given randonly generated ids. If that node logs an error, you see the generated ID, not the ‘true’ id as appears in the editor. It gets harder when you have nested subflows because you need to be able to identify which instance of the node, in which instance of the subflow to go looking for.

The path property can solve that by providing the ids of the top-level flow and each subflow instance to identify exactly where the node is.

This property is exposed in the following ways:

For node authors, it is available as this._path on the node object.
Inside the Function node, it is exposed as node.path.
It is also available as the environment variable NR_NODE_PATH when evaluated by a node.

Node Updates

The JSON node will now attempt to parse Buffer objects if they contain a valid string
The TCP Client nodes support TLS connections
The WebSocket client node now lets you specify a sub-protocol to connect with

What’s next?

Next on the release plan is Node-RED 3.0, scheduled for the end of April.

This coincides with Node.js 12 reaching its end of life.

As ever, if there are any particular features you’re interested in, now is a great time to jump into the forum to share your feedback.

Version 2.1 released

2021-10-21T00:00:00+00:00

Node-RED 2.1 is now available to install. If upgrading, please read the upgrade instructions.

The Change Log has the full list of changes in this release, but here are the highlights.

Highlights
Other node updates
Documentation Updates
What’s next?

Highlights

New Welcome Tour Guide

The first time you open the editor with 2.1.0, you will be greeted with a new Welcome Tour. This will highlight a lot of the new features in this version.

The Tour will only be shown the first time you open any particular version of Node-RED - and you can opt-out of seeing them in the future in the User Settings dialog.

If you embed Node-RED in your own application and don’t want the tour to be shown to your users, then it can also be disabled in the settings file.

The underlying framework for creating the Welcome Tour can be reused to create other interactive tours/tutorials/guides. We’ll have more on this area in the future.

Hiding tabs

We often hear from users who have a lot of flows. To make it a bit easier to manage, you can now hide their tabs in the editor.

The Info sidebar still lists them all, and indicates which are currently hidden. It also allows them to be shown with a single click.

There’s also a new tab menu that provides more options around managing the tabs.

For this first release of the feature, the hidden state of a tab is stored in user preferences within the editor - it is not a property of the flow itself. This means you can’t share a set of flows with another user and have some of the tabs pre-hidden. It is an open point of discussion as to whether we want to allow that behaviour.

Whilst talking about managing the tabs, shift-clicking on the workspace tab bar scroll arrows will now jump immediately to the start/end of the tab list.

Dynamic MQTT nodes

The MQTT In node now includes a ‘Dynamic subscription’ option. When selected, the node gets an input so you can pass it messages. Those messages can be used to:

connect/disconnect the broker
subscribe to topics
unsubscribe from topics

The MQTT Out node also supports the connect/disconnect messages as well.

The MQTT Broker configuration node has a new ‘connect automatically’ option - which is enabled by default. If you disable that, it won’t connect until one of the flow nodes receives a connect message.

Full details of the formats of those messages are in the node help and summarised in the pull-request here.

Auto-complete in `msg` TypedInputs

The msg TypedInputs are used widely throughout Node-RED. To make life a bit easier, they now provide auto-complete when typing message property names.

For now, it offers completions from the list of well-known properties the core nodes use.

In the future, it will be possible for contrib nodes to register the properties they use so they can be offered as completions as well.

We’re also thinking about how best to apply this to flow/global inputs - auto-completing based on the current contents of context.

New Link Call node

The new Link Call node can be used alongside the Link-In/Out nodes to create subroutine-like flows.

If you have a flow that starts with a Link-In node and ends with a Link-Out node that has been put into its new ‘return’ mode (giving the node a different icon), the Link Call node can be used to pass that flow a message and the result is passed back to the calling node.

As an alternative to using subflows, this is great for creating little utility flows that you want to reuse in multiple places.

Edit & Arrange menus

The main menu now has Edit and Arrange submenus.

The Edit menu has the actions you’d expect - Undo, Redo, Copy and Paste etc.

The Arrange menu adds tools to help arrange your nodes.

All of the menus now also show any keyboard shortcuts that have been set.

Flow/Group level environment variables

We have supported Environment Variables being set within Subflows for a while now. With this release, you can now also set them at the Flow or Group level.

Other node updates

The Debug sidebar options have been reworked.

The filter options are now a drop-down menu of options, rather than the sliding panel.

The ‘clear messages’ button now also has a drop-down that lets you change it to ‘clear filtered messages’ instead. That option is useful if you have the ‘current flow’ filter enabled, and you want to clear the message for the current flow without clearing messages from other flows.

In other good news, both of these options are now stored in the editor settings - so they are remembered between editor reloads.

Deep copy option on Change node

The Change node’s “set” action has a new option to create a deep copy of the value when copying from msg, flow or global.

In the case of Objects and Arrays, this creates a proper clone of the value, rather than creating a reference to the same object.

We’ve also updated the label of the “set” action to hopefully help users get the ‘from’ and ‘to’ fields the right way around.

Delay node updates

When in rate limiting mode, the Delay node supports two new features:

if msg.toFront is set, a message is put to the front of the queue of messages waiting to be sent
there’s a new option to send rate limited messages to an optional second output on the node. This is useful if you need to rate limit messages and do some further processing for the messages that have been rate limited, rather than just have them discarded. For example, if you are creating a rate limited HTTP endpoint, you still want to be able to respond to the rate limited requests rather than just letting them time out.

Join node reset timeout

If the Join node has a timeout running and it receives a message with msg.restartTimeout set, it will restart the timeout.

TCP Request node can return Strings

The TCP Request node can now be configured to return Strings rather than raw Buffers. This matches the functionality already available with the TCP In node.

File nodes renamed

The file and file in nodes have new palette labels to make it clearer which writes to files and which reads from files. Even after all this time, I would have to double check which was which.

Documentation Updates

Whilst not really part of the release, we’ve also published lots of updates to the API documentation on the website.

This includes the hooks and library store APIs in the runtime.

The docs now cover more of the APIs available to nodes and plugins to extend the UI.

There is also documentation on creating custom Theme plugins.

What’s next?

This release has got us back on schedule for our release plan. With that plan, the next release, 2.2 is scheduled for the end of January.

There are a few features already in development for that release, including tooling to help package subflows as npm modules directly from the editor.

As ever, if there are any particular features you’re interested in, now is a great time to jump into the forum to share your feedback.

Version 2.0 released

2021-07-20T00:00:00+00:00

Node-RED 2.0 is now available to install. If upgrading, please read the upgrade instructions.

The Change Log has the full list of changes in this release, but here are the highlights.

Node.js 12 or later required
Runtime Features
Editor Features
- Monaco Text Editor
- CSS Theme Variables
Node updates
Extending the Developer Experience
- Flow Debugger
- Flow Linter - nrlint
What’s next

The main focus of this release has been dropping support for old versions of Node.js that are themselves no longer supported. This in turn has allowed us to make some major dependency updates internally. This has required time and effort to do properly. As such, there are not a lot of big new features in this release - but there are certainly plenty of useful things to play with.

We’re also releasing the first versions of the Node-RED Flow Debugger and Linter. These are optional plugins that really step up the developer experience within the Node-RED editor. Before we get to them, lets look at what’s new in the Node-RED core.

Node.js 12.17.x or later required

Node-RED 2.0 does not support anything earlier than Node.js 12.17.x.

Runtime Features

`node-red admin init` command

We’ve added a new command-line option to node-red to help you generate a settings file.

It asks you a series of questions about how you want to configure your Node-RED environment, such as setting up user security.

This makes it much easier to get started with a well configured, secure Node-RED environment.

You can run it using the node-red admin command:

node-red admin init

More details

Restructured default settings file

Along with the new node-red admin init command, we’ve reorganised the default settings file. The settings are now in a better order, with clearer sections to help users navigate.

You can see the new default settings file here.

Default flows file name

We’ve updated the default settings file to hardcode the flow file name to flows.json. Previously we left it unset, so the runtime would use the hostname to generate the flow file name. That would catch people out when moving between networks. As this is a change to the default settings file, all existing installs will continue to behave as they did before.

Editor Features

Monaco Text Editor

We now have optional support for the Monaco text editor. This gives a much richer code editing experience in the Function node and elsewhere.

For now, Node-RED will still use the ACE editor by default. To enable Monaco you need to edit the editorTheme section of your settings file to include a codeEditor section like this:

editorTheme: {
    codeEditor: {
        lib: "monaco"
    }
},

We tested this editor against a lot of the more commonly used nodes to ensure they work with Monaco, but it is possible there are contrib nodes out there that assume the editor uses ACE. If you hit any problems, please let us know so we can raise with the module owner.

CSS Theme Variables

To make it easier for nodes/plugins to style their UI elements so they honour any custom theme applied, we’ve added a selection of CSS Variables they can use to pick-up theme colours.

More details

Node updates

Function external module changes

In the last release, we made it easier for the Function node to use external modules. Once enabled in your settings file, you could then configure what modules the Function node used in its edit dialog.

Based on feedback on the feature we’ve made the following changes in this release:

The feature is now enabled by default for new installs. To disable it you will need to set functionExternalModules to false.
The UI has been reworked to give a cleaner list of the modules and what variable they will be available as.
We now support both CJS modules and ES6 modules.
We have moved the directory the modules are install in back to the top-level of your user directory. This means there is a single package.json that lists all of your dependencies. The first time you run 2.0, it will automatically reinstall any external modules in the new location.

Inject node quick inject button

The Inject node has a new button in its edit dialog that will trigger the Inject node with the values from the edit dialog, rather than the values currently deployed. That makes it much easier to quickly inject different values whilst testing a flow.

Note the button in the main flow view will still inject the current deployed values as it always has.

Renamed `RBE` node to `Filter` node

The RBE (Report By Exception) node is one of the hidden gems of the palette. Given how many times its the answer to a question on the forum, it’s clear we needed to make it more discoverable. With this release we have done two things:

added it to the core palette (it was previously installed via the node-red-node-rbe module)
rebranded it the filter node.

Under the covers it still uses the rbe node type, so existing flows will not be affected. Also that means it will still show up if you search for rbe - so users following existing guides will still find it.

Giving it the name filter should help users find it and more instinctively understand what it is for. It also opens up the option of adding more filtering options in the future that wouldn’t have fitted under the ‘RBE’ name.

Removed `tail` node

We have removed node-red-node-tail as a default dependency. This means you may need to manually install that module to get the node back if your flows use it.

Other node updates

A new settings is available, fileWorkingDirectory that can be used to define the working directory used by the File nodes to resolve relative paths. If the setting isn’t provided, the nodes will do what they did before - use the current working directory of the Node-RED process.
When in rate-limiting mode, the Delay node can now dynamically set its rate using msg.rate.
The TLS node now allows you to specify an ALPN protocol
Debug sidebar supports displaying Map/Set type properties
The File In node has a new option to include all properties when sending a message per line
The Exec node has a new option to hide the console window when running under Windows
The Delay node can now be told to flush a set number of queued messages using msg.flush
The WebSocket client node can be configured to send a heartbeat ping message automatically

Extending the developer experience

One of the benefits of low-code programming with tools like Node-RED, is it abstracts away a lot of the technical detail of how things are working. It allows you to focus on solving the problem at hand.

But just because it’s low-code, that doesn’t mean you can’t have the tools you need to make high quality applications and to help debug when things aren’t going as they should.

To that end, we’re also releasing a pair of new plugins for Node-RED that will bring a step-change to the overall developer experience.

Flow Debugger

First up is a Flow Debugger. This acts like regular code debuggers, but at the flow level. You can set breakpoints on node ports, either inputs or outputs. Then, whenever a message arrives at a breakpoint, it pauses either at that node, or the entire runtime.

Once paused, it then shows you how many messages are queued up at each point in the flow and in the sidebar you can see the queue of messages in the order they will be processed. From there, you can step each message through the flow, or even delete it mid-flow.

For more information, you can find the plugin page here.

Flow Linter - nrlint

The second plugin we’ve released is the Flow Linter - nrlint. This can be used to identify potential problems in the flow based on a large set of rules the linter provides. For example, it can warn if you have HTTP In nodes that aren’t connected to HTTP Response nodes. Or if you have nodes that are physically overlapping and potentially obscuring each other.

We’ve modelled the linter after eslint which we also bundle in one of the rules that can be used to lint the JavaScript in your Function nodes.

We’ve designed the linter to run in the browser using a Worker thread - meaning it doesn’t impact the performance of the editor. The sidebar shows you the linter results and lets you quickly navigate to the areas of the flow that need attention.

Outside of the editor, nrlint can also be installed and run as a command-line tool against flow json files. This means it can be used to validate flows in build pipelines.

Today we have a minimal set of rules and a recent call for input from the community has generated a long list of great ideas.

We’re sure there will be some slightly more esoteric rules that perhaps don’t belong in the core set. For example, some third party nodes may want to introduce guidance about how their nodes are used. So to support that, the linter rules are pluggable - allowing custom rules to be created and shared with the community via npm.

For more information, you can find the plugin page here.

What’s next?

The release plan we published last year had targeted 2.0 to be released at the end of April and for subsequent milestone releases to happen every 3 months after that. Given we’re already three months beyond that April target, we need to look again at our release planning.

The 2.0 release has been somewhat unique. It’s our first major version bump that has unblocked a number of internal changes as we no longer have to worry about old versions of Node.js. But it has taken longer than expected to sort out those internal changes, including a couple upstream issues that blocked progress for a while.

We really want to get back to a regular release cadence - having a predictable release date that is well known and we all work towards. That’s something we’ll be figuring out as we move forward. But today, we reset the clock and shift our attention to 2.1 that will be released in late October.

If there’s a particular feature you’re interested in seeing in Node-RED, then now is the time to jump into the forum and share your feedback.

As for the 1.x stream, it is now in maintenance mode. That means we will still do maintenance releases as and when needed if there are bugs reported and fixes available.

For the contributors out there, we’ll be shuffling around our code branches in github to reflect the different streams we now have - we’ll share more details via the #core-dev channel in slack, so do come say hello if you’re interested.

バージョン1.3がリリースされました

2021-04-08T00:00:00+00:00

Node-RED 1.3がインストールできるようになりました。もし、アップデートをしたい場合は、アップグレード手順を参照してください。

Change Logには、本リリースの全ての変更内容が掲載されています。ここでは、概要を紹介します。

このリリースは、Node.js 8と10で実行できる最後のリリースであることにご注意ください。

これらのバージョンのNode.jsはEnd-of-lifeになるため、来月にリリースするNode-RED 2.0では、これらをサポート外とする予定です。

*リリースに関する動画は近々公開します - 見逃さないよう、チャンネル登録をしてください。

注目機能
エディタの機能
ランタイムの機能
- 新しいexternalModules設定
- その他のランタイムの更新
ノードの機能

注目機能

Functionノードにおけるnpmモジュールの利用

Functionノードにおいて、外部のnpmモジュールをより簡単に利用できるようになりました。

settingsファイルで functionExternalModules を true に変更することで、functionノードにおいて、利用したい追加モジュールを設定できるようになります。フローをデプロイした際に、ランタイムは自動的にこれらのモジュールのインストールを試みるようになります。

functionノードでモジュールを使用する前に、グローバルコンテキストからモジュールを取得する必要がある functionGlobalContext のアプローチとは異なり、本新機能では読み込むモジュールはコードに定義され、自動的に取得されます。

編集ダイアログには新たに 設定 タブが追加され、ノードの出力数やノードで用いるモジュールを設定できるようになっています(もし functionExternalModules の設定を有効にしていない場合は、出力数のフィールドのみが表示されます)。

他のタブにおいては、各タブ内のコードがいつ実行されるか分かりやすくなるように、名前が付け替えられています。

詳細

Change/Switchノードでのmsgプロパティの参照

ChangeノードとSwitchノードにおいて、メッセージのプロパティのネストした参照ができるようになりました。

例えば、複数のセンサーから温度を取得する場合です。各メッセージは、センサーが設置された部屋が設定された msg.topic と、値である msg.payload を持っています。例えば flow.rooms.kitchen や flow.rooms.garage のような flow.rooms のコンテキストに、各部屋の現在の温度を保存したいとします。

これを以前のバージョンのNode-REDのChangeノードで行うには、JSONataを使用する必要がありました。例えば:

flow.rooms に、式 $merge([$flowContext('rooms'),{$.topic:$.payload}]) を代入

多くの場合、ユーザはfunctionノードでの実装に陥りますが、これは避けた方が良いでしょう。

1.3では、次のようにChangeノードで設定できるようになりました:

flow.rooms[msg.topic] に msg.payload の値を代入

実際には RED.util.getMessageProperty(...) ユーティリティを用いる全てのノードが、この機能を持っています。

詳細

Node-REDプラグインフレームワーク

Node-REDのカスタマイズや新機能追加を容易にするため、プラグインフレームワークを新たに導入しました。この機能は初期段階ですが、将来的には、沢山の新しいもの追加するための基礎となります。追加機能を本体のコードではなくプラグインとして提供することで、本体を小さく保ち、Node-REDを組み込んだアプリケーションが、より簡単に「追加」機能を選択できるようになります。

詳細

この新しいフレームワークを用いた、2つの種類のプラグインが今日利用できます:

エディタテーマ プラグイン　新しいテーマのインストールや、settingsファイルでの有効化を簡単にします。詳細.

コントリビューションされたテーマの良いコレクションがここにあります。これらテーマは更新されるため、プラグインのバージョンに注意してください。
ライブラリソース プラグイン　エディタ内の読み込み/書き出しダイアログに表示される追加ライブラリを構成できます。最初の例として、ローカルファイルシステムプラグイン (@node-red/library-file-store) を公開しています。詳細

リソースの追加

プラグインとノードには、エディタに追加のリソースを読み込めるようにするという共通の要件があります。これは、ヘルプのテキストに画像やJavaScriptライブラリを追加するものです。

以前は、ノードでリソースを読み込めるようにするために、沢山の追加作業が必要でした。

プラグインフレームワークでは、これを簡単に実現できます。ノードにおいても同様に適用できるようになっています。

現在、モジュールが一番上の階層に resources というフォルダを持つ場合は、ランタイムは自動的にその中のコンテンツをAdmin HTTP APIを介して読み込めるようになっています。

エディタでコンテンツをロードすることは必要ですが、ノード/プラグインはランタイムにおいてコンテンツを提供するルートを作成する必要はありません。

ノードの開発に関するドキュメントは、さらに詳細が追加され更新されています。

npmパッケージ化されたサブフロー

現在、サブフローをモジュールとしてパッケージ化してnpmに公開し、他のノードと同じようにパレットにインストールできるようになっています。

この一環として、サブフローのプロパティ編集ダイアログは、新しい ‘モジュールプロパティ’ タブを持っています。ここに、npmモジュールを生成する際に使われるサブフローに関する任意のメタデータを設定することができます。

モジュールを生成する手順は、現在は完全に手作業です。手順の詳細は、ノードの開発ガイドのセクションに追加されています。

詳細

エディタの機能

書き出しのプレビュー

書き出しダイアログは、現在書き出そうとしているものを表示する構造化された一覧を表示します。素のJSONは、タブ内の2つ目に引き続き表示されます。これは、ユーザが何を書き出そうとしているか理解するために役立ちます。

ノードの選択

シフトキーを押しながらノードをクリックすると、フロー内の全てのノードが自動的に選択される機能は以前から実現されています。

このリリースでは、シフトキーを押しながらノードの左側をクリックすると、フローの前側の全てのノードが選択されます。一方、シフトキーを押しながらノードの右側をクリックすると、フローの後ろ側の全てのノードが選択されます。シフトキーを押しながらノードの中心をクリックした場合は、以前と同様にフロー全体を選択します。

これらに対応するデフォルトのキーボードショートカットが追加されています:

core:select-connected-nodes - alt-s c - 現在選択されているノードに接続されている全てのノードを選択
core:select-upstream-nodes- alt-s u - 現在選択されているノードの入力から到達可能な全てのノードを選択
core:select-downstream-nodes - alt-s d - 現在選択されているノードの全ての出力から到達できる全てのノードを選択

詳細

サブフローの開き方

以前は、サブフローを開くために、最初にワークスペース上のインスタンスをダブルクリックする必要がありました。その後、編集ダイアログにある「サブフローを編集」ボタンをクリックしていました。

このリリースでは、ノードをダブルクリックする時に、Ctrlキー(MacではCmdキー)を押していると、直接サブフローのテンプレートタブに移動できます。同じように、サブフローのインスタンスが選択された状態で、Ctrlキー(Cmdキー)を押しながらエンターキーを押すと、同様の動作となります。

ワークスペースのナビゲート

ワークスペース内を移動するのを助けるキーボードショートカットがいくつか追加されています。

ワークスペースで選択されているノードを矢印キーで切り替え。
Ctrl/Cmd-[ や Ctrl/Cmd-] を用いてタブ間を切り替え。
Ctrl-Enter を用いてサブフローのテンプレートタブへ移動、Ctrl/Cmd-Shift-左矢印キー を用いて最後に開いていたタブへ移動。元のタブに戻った場合は、Ctrl/Cmd-Shift-右矢印キー を用いて、タブの履歴上で前に戻ることもできます。

キーボードショートカット

settingsファイルの editorTheme オプションを介して、カスタムのキーボードショートカットを設定できるようになりました。これによって、複数のインスタンス間でカスタマイズをより簡単に反映できるようになりました。詳細

その他のエディタの更新

エディタをリロードした時に、常に直近使ったタブを表示するようになりました。
サブフローを削除する時に、使用中のインスタンスがある場合、確認ダイアログを表示します。
情報サイドバーにあるアウトラインビューに、各サブフローが使用されているインスタンスの数を表示するようになりました。この数値をクリックすると、それらを一覧表示する検索ダイアログが表示されます。
アウトラインビューでクリックするのみで、グループ内のコンテンツに対して、状態の有効/無効の切り替えができます。

ランタイムの機能

新しい`externalModules`設定

Node-REDにインストールできるものを管理するための新しい設定、externalModules を利用できるようになりました。

この設定は、2つの別々のものをカバーしています。1つ目は、パレットマネージャを介してインストールできる新しいノードです。2つ目は、functionノードによって読み込むことのできるモジュールです。

この設定で、ランタイムによって読み込むことのできるモジュールを決定するために使われる allow と deny リストを提供できます。これらは、パレットマネージャーに表示されるノードの一覧を絞り込むために、エディタにおいても利用されます。

この新しい設定は、現在非推奨となっているいくつかの既存設定を置き換えるものです。

editorTheme.palette.editable は externalModules.palette.allowInstall　に置き換え
autoInstallModules は、 externalModules.palette.allowInstall = true と externalModules.autoInstall = true に置き換え
autoInstallModulesRetry は externalModules.autoInstallRetry に置き換え
editorTheme.palette.upload は externalModules.palette.allowUpload に置き換え

詳細

その他のランタイムの更新

settingsファイルの lang オプションを介して、ランタイムが使用する言語を明示的に設定できるようになりました。詳細
フローが停止される時に、設定ノードは最後に停止されるようになりました。これによってフローのノードは停止される時に、設定ノードに頼る処理を行えます。詳細
settingsファイルの editorTheme.projects.workflow オプションを介して、簡素化されたgitワークフローをデフォルトに設定できます。詳細
httpAdminMiddleware と httpNodeMiddleware は、1つの関数のみしか使えませんでしたが、現在は配列として複数のミドルウエアを設定できるようになりました。詳細

ノードの機能

MQTTノードはMQTTv5をサポートし、v5で提供されている新機能の大部分を使えるようになりました。
Batch、Delay、Split、Join、Triggerなど、多くのコアノードがCompleteノードへトリガできるよう更新が入りました。
Execノードは、コマンド引数に msg.payload をデフォルトで追加しなくなりました。これは、ユーザによってよく除かれているためです。これは 新しく追加された ノードにおいてのみ適用され、既存のノードについては影響を受けません。また、msg.payload だけではなく、任意のメッセージプロパティを追加できるようExecノードが更新されました。
InjectやChangeノードは、編集ダイアログを閉じた時に、設定のエラーをハイライト表示するようになりました。
Functionノードでは、設定されたポートの出力数をコードから参照できるように node.outputCount が利用できるようになりました。

Version 1.2 released

2020-10-15T00:00:00+00:00

Node-RED 1.2 is now available to install.

If upgrading, please read the upgrade instructions.

Editor Updates
Runtime features
- Splitting .config.json into multiple files
- Introducing RED.hooks api
Node updates

Editor Updates

Importing duplicate nodes

In previous releases, when you import a flow, all of its nodes are assigned new identifiers. This meant that if you imported the flow again, you’d get a second copy. If that flow included configuration nodes or subflows that were identical to ones you already had, the editor would avoid importing a duplicate copy and reuse the existing one.

That has generally worked well, but on some occasions it wasn’t ideal. In particular, if you wanted to import an update to a subflow you are using, there was no easy way to do it - it would be imported as a new subflow and you’d have to manually update all the instances to the new subflow.

With this release, when you import a flow that contains nodes you already have, the editor will now ask you what to do. In the case of Subflows and Configuration nodes, it gives you the option of replacing the instances you already have, rather than importing a copy.

More details

Simplified Git Workflow

The projects feature now provides an option for a simplified git workflow. The option, under User Settings, lets you enable an ‘automatic’ mode where changes will be automatically committed with every deploy.

More details

Other project enhancements include:

the project settings dialog also now lets you edit the project’s version string.
the flowFilePretty option is now automatically enabled for projects unless explicitly set to false

Handling ‘lost’ nodes

We’ve seen a very small number of instances where a node forgets what tab it is on and its z property is set to 0 or "" - causing the node to disappear from the editor. We’ve never managed to recreate this issue to get to the bottom of it - something to do with deleting flows. But with this release, the editor will now help recover those lost nodes by added a ‘recovery’ tab to add them to.

More details

Other editor features

Sidebar tabs can now be reordered (details)
The palette manager has an option to upload a node module tgz file rather than install from the catalog. This can be disabled in the settings. (details)
The ACE edit component has been updated to the latest version which brings much better support for ES6 JavaScript syntax
Fixes issues around copy/paste of nodes within groups causing lockups.
When merging groups, the style options of the first selected group is used for the combined group.

Runtime features

Splitting `.config.json` into multiple files

The runtime settings file, .config.json has been split in to four separate files to better organise the content and allow the user to be more selective over what they version control.

If you have a backup script that includes .config.json you will need to update it to backup these other files instead.

The runtime will leave the existing .config.json in place in case you chose to downgrade, but it will no longer be updated.

More details

Introducing `RED.hooks` api

This is part of the pluggable message routing work that has been in our roadmap for a long time now. It is less relevant to end users at this point in time, but will underpin a lot of exciting features in the future, such as a proper flow debugger, distributed node-red runtimes and integrated flow testing.

More details

Node Features

The Trigger node can now be configured to set its delay/repeat-interval by msg.delay
The Function node’s “setup” code can now log and send messages (details)
More of the core nodes now implement the ‘done’ api so can be used with the Complete node - yaml, xml, json, html, http, template, range, link, status, catch , complete, inject. Work continues on the remaining nodes.

What's next with Node-RED?

2020-10-13T00:00:00+00:00

Last week I presented at Node-RED Con Tokyo to talk about the future of the project. I spoke about the high-level goals for project and what they translate to in terms of technical features in the roadmap.

This blog post is the written form of that talk - it provides the context that is otherwise lacking from just looking through the slides.

In my last post, I wrote about how we plan to schedule our releases - with a new major versions being published to coincide with the Node.js release schedule.

What I didn’t touch on in that post is the technical side of the roadmap. Aside from keeping up to date with Node.js, the question is what have we got planned for the future of the project.

The roadmap for the 1.0 release gave us something to focus on - it set a reasonably well-defined target for the project to get to. Looking beyond 1.0 is a much more open-ended question - there isn’t an equivalent end-point in mind.

We do have a set of goals of the project - things we know we want to achieve. We can use those goals to identify and prioritise the technical features we’re going to work on in the coming releases.

In this post, I’m going share some of the technical features we have planned for the project and how they fit in with our goals for the project’s future.

But first I wanted to share what we see our goals as being.

Who are our users?

To begin thinking about what the technical roadmap is for the project, we have to take a step back and think about who our users are - who are we developing Node-RED for?

The community survey we did last year gave us a good view of the community. Our users come from a very wide range of backgrounds and experience. We have students who are just starting to learn about programming. We have retired engineers who are getting back to building things. We have experienced developers who appreciate the convenience Node-RED provides over writing code. And we have everyone else in between.

A large proportion of our users are individuals who run Node-RED on personal devices - a laptop, a Raspberry Pi or a virtual machine in the cloud. They are building solutions for themselves - whether it’s home automation, adding skills to their Alexa or Google Home, or doing the types of online services like IFTTT can provide.

It’s predominately these users who spend their time in the forum, discussing what they’ve built, or helping answer questions from newcomers.

Another group of users come from the companies who have integrated Node-RED into their own products and services. Hitachi, Siemens, Samsung, Particle and many others. They have a different set of needs. They want to integrate Node-RED into their existing platforms. They want to be able to offer a seamless experience to their end users - hiding away the details of how Node-RED is being run or where the flows are executed.

Understanding the different needs of these groups of users is vital to getting the priorities right in the roadmap.

Sustainability

There is another reason why we need to understand these different groups of users. We have a responsibility to ensure Node-RED is a sustainable project - that it has the resources it needs to continue delivering to our users. Sustainability in open source is a hard problem.

Contributors typically come from two places; individuals who chose to invest their spare time to the project and individuals who have a commercial interest in the project and contribute as part of their day job.

As a Growth project of the OpenJS Foundation, we want to grow our contributor base - getting more people involved with the central parts of the project.

Whilst some of that will come from individuals, we want to increase the commercial adoption of Node-RED. This will help increase the commercial investment back into the project itself.

Project goals

As we think about the technical roadmap for the project, we have three goals:

Improve the experience for the individual developer
Increase commercial adoption of Node-RED
Improve the path to production for anyone wanting to use Node-RED

It’s these goals that we should use to help us prioritise and focus our efforts moving forward.

A lot of this will be familiar if you’ve followed the various discussions in the forum or slack - but it’s useful to bring it together into one place.

Improving the Developer Experience

Testing Framework

One of the most fundamental requirements for any software development is being able to easily test the code. Whether that is unit-testing individual components, or system-testing a larger piece.

This is an entire area that Node-RED does not provide much help to the user with. Some testing can be done in the editor, using Inject nodes to create test messages, and the Debug sidebar to check the results. But that’s quite a limited set of tools. It’s entirely manual testing and not suitable when you want to test against external systems like databases or web apis, nor is it suitable when you want to automate the testing as part of a automated Continual Integration workflow.

One approach would be to create traditional test cases in code; tests that can run against the externals exposed by the flows. This has two major drawbacks; it would be hard to do unit testing of internal components of the flows, and it does not fit the ‘low-code’ idea of Node-RED very well.

We want our users who are not traditional software developers to be able to create tests for their flows just as easily as anyone else can.

There is some initial design work on this item in our designs repository. The high-level concept is to be able to define suites of test cases in the editor. Then, for each node in a flow, you will be able to define the desired behaviour of that node for each test case. The behaviour will be split into three phases:

beforeNode - this phase is triggered when a node receives a message, but before the node is given the message. This can be used to validate the message arriving at the node has the expected properties.
testNode - this phase can be used to define the behaviour of the node in place of the actual runtime node. This would allow the node to be ’stubbed’ out, for example a node that writes to a database or interacts with an external system.
afterNode - this phase is triggered whenever the node sends a message, but before the next nodes receive it. This can be used to validate the output of the node.

Any of these phases will be able to mark the test case as having passed or failed. That means it would be possible to create test cases that span entire flows, or that just focus on one or two nodes.

The editor will have a new sidebar that lists out the test cases, where they can be run and have their results reported. We’ll also provide a way of running the test cases using just the command-line so they can be used as part of an automated pipeline.

Flow Linter

Alongside testing, there’s another type of tool that developers have come to expect and rely on in modern development tools - linters.

Linters are tools that can analyse the code and generate recommendations, warnings and errors based on what they find. From checking for basic syntax errors, to ensuring a consistent format is used in a code base, linters play an important role.

There has been some initial work on a Flow Linter from our friends at Hitachi, and we’ll be looking to accelerate that work in the coming months.

The Flow Linter will be both command-line and editor based. The command-line version will allow it to be used as part of deployment pipelines to ensure a flow meets the required linting rules before it is integrated.

Within the editor, it’ll give feedback to the user over issues in their flow, before they have even clicked the Deploy button.

It will be a pluggable tool, allowing custom linting rules to be written and shared with the community - so if your organisation has a particular set of requirements, or maybe you use some custom nodes that must be wired up in very particular ways, the linter will help catch mistakes before they are deployed.

Flow Debugger

One of the features that I am personally most excited to start working on is a proper flow debugger.

Node-RED provides the Debug node to help the developer understand what is happening in their flow. They are helpful tools, but they have their limits. You can only debug at the points you have added a node into the flow. Where you have a flow that involves multiple branches and timing events, it can be hard to see how messages are flowing in each branch at the same time.

The Flow Debugger will allow the developer to set breakpoints throughout their flow. When a message arrives at a breakpoint, the runtime will pause, messages will stop flowing. The developer can then inspect the flow at different points - to inspect the messages waiting to be delivered.

When running with the Debugger enabled, the user will be able to visualise the performance of their flows - to see where time is being spent, or if there are any bottlenecks that could be optimised.

Exportable Subflows

We want to make it easier for users to create their own nodes and share them with the community. The goal is to allow subflows to be published as proper node modules that can then be installed just like any other node in the library.

Work is already well underway on this - there’s a draft PR that adds basic support for loading subflows into the runtime from a module.

Projects

We have had the projects feature in Node-RED for a long time now - bringing the ability to version control flows directly into the editor. But there’s more to be done in this area.

The 1.2 release has introduced a new simplified git workflow - where changes are automatically committed whenever the deploy button is clicked. That’s important for users who are less experienced with Git version control - they will benefit without having to know about committing changes themselves.

And there are other areas we need to improve:

Managing project dependencies. At the moment the editor lets you edit the dependencies yourself, and it tries to give some hints on what needs doing, but that whole user experience needs to be improved.
Accessing earlier versions of a project. Having a full history of changes is not much use if you can’t easily go back to an earlier version. It is possible to do on the command-line - but that isn’t the right answer if we want this to be accessible to all users within the editor.
Adding settings.js to a project. For a project to be a complete deployable artefact, it needs a settings file. At the moment, that has to be created and added to the project manually. There’s more the editor could do to help with this - the hard part is managing the project’s settings file versus the runtime settings file - but that’s a discussion for another time.
Adding a Dockerfile to a project. A common pattern for deploying projects into a production environment is via some form of containerisation. Making this quick and easy to setup in the editor would be a big step forward - although very much an optional feature.

I’m sure there are other things we could be doing with the Projects feature to make it much more powerful. As with everything on this roadmap, we’ll be looking to the community for feedback to help expand on the details.

Standalone Installer

Another area we want to improve is making it easier for users to get started with Node-RED. At the moment, to install Node-RED a user has to install node.js and npm, then run some commands they may not be familiar with, and they see a screenful of output from npm - most of which will mean very little to them.

There are also the cases where a user doesn’t have a good internet connection - or any connection at all where they want to install Node-RED.

To help address these problems, we’re going to create a standalone installer for Node-RED. Built with Electron to generate native installers for all the common platforms, this will be a way to install and use Node-RED as a native desktop application.

There are existing projects that do this - including Saito-san’s Node-RED Desktop. We’ll look to those projects for collaboration and inspiration as we move forward.

Increasing commercial adoption

An important goal for the project is to increase its commercial adoption. It’s through this we can help increase the investment back into the project and help increase its long-term sustainability.

All of the developer experience items feed into this as Node-RED will only get adopted if there is a demand for it - so ensuring it is a delight to use and provides the tools users want to use is vital.

But there are also a set of features that are of less immediate relevance to individual users - but will play an important role when looking at running Node-RED at scale.

Deploying Node-RED at scale

One very common question we get is around multi-tenancy - having multiple users share a single Node-RED instance without getting in each other’s way.

Our long-stated recommendation has been that the node-red runtime is not suited for multi-tenancy. This is down to a number of reasons. Node.js is a single-threaded runtime - there is only one event loop that must be shared between all of the flows in the runtime. If one user creates a flow that uses a lot of resources, it could have a negative impact on the performance of the other flows. Any bugs in that flow that lock up the event loop would stop everything else from running. Similarly, we have no mechanism to isolate the global context of each flow.

This is why we have always said each user’s flows should be put in its own runtime instance - and we have no immediate plans to change that recommendation.

But we recognise that hands the responsibility for figuring out how to manage multiple instances over to those who want to integrate Node-RED into their environment. That can be quite a barrier to adoption and we don’t currently provide any guidance on how to do it.

To begin with, we want to understand how the existing users of Node-RED have approached deploying it at scale. We know there are lots of different possible models and approaches taken today. We want to get a better view on questions like what stacks are being used - is it Kubernetes, OpenShift, Docker Compose or some other orchestration technology. We want to understand what approaches companies have taken to manage their user’s flows. Do users edit their flows in a ‘live’ environment or are there separate development and production runtimes.

This will then feed into a set of architectural patterns we’ll create for deploying Node-RED at scale. In the first instance, those patterns may be more about documentation than running code. Over time, there may prove to be some useful components we can develop that would fill in some of the gaps.

Scalability of flows

As workloads increase, we need to ensure the Node-RED runtime can be scaled to meet the demand.

As with the multi-tenancy question, we’ve traditionally deferred this question to say you can horizontally scale your flows by running multiple instances of the runtime, with some kind of load balancing in front.

That answer remains largely the same, but there are certainly things we can do to help with the overall scalability.

We’ve talked about the idea of a distributed Node-RED architecture many times in the past. This is where a flow drawn in the editor can be deployed across multiple runtimes and devices. It is something we’ve been slowing working towards and we’ll continue to do so.

It’s a model that can also be used in the context of scalability. For example, being able to deploy multiple copies of a flow across multiple runtimes.

In 1.2 we’ve added the hooks API to support pluggable message routing. This will allow custom code to be added to the message routing between nodes. So if a flow spans two different runtimes, or different parts can be scaled independently, that custom code could be used to route the messages between the runtimes.

In 1.0 we added the Groups feature in the editor. The plan is, in a future release, to allow a group to have custom meta data associated with it. A user could then create a flow, and then group the nodes according to where they should be deployed, or how they can be scaled. That group meta data could then be used by the messaging routing to handle getting the messages to where they need to be. Aside from the group meta-data, the only other missing piece is a way to deploy the flow across the multiple runtimes.

The new hooks api we introduced in 1.2 for the message routing will get extended in a future release to support hooks at other points of the runtime lifecycle - such as when the deploy button is pressed.

The key part here is we’re adding the components and APIs needed to build a distributed Node-RED. We don’t plan at this stage to produce an out-of-the-box Distributed Node-RED version - but all the parts will be there to do so.

Customising the Node-RED flow appearance

Another aspect is looking at how easy it is to customise the appearance of Node-RED. We already provide ways to add custom CSS and modify some aspects of the editor, but that can only go so far.

We have had occasional requests to be able to customise the appearance of the flow itself - the shape and design of the nodes.

We plan to make the drawing of flows a pluggable component of the editor. It is only a concept at this stage - I couldn’t say exactly how it would work, but the idea would be that when the editor needs to draw a node on the screen at a given position, it calls out to the custom code that does the work needed.

To be clear, this isn’t about allowing individual nodes to change their own appearance - its about customising the appearance of the entire flow in a consistent way.

Feedback

With all of these features, there is a significant amount of development work needed. As an Open Source project without a large team of full-time developers, it isn’t possible to put a time-scale on this work as a whole. These items are only the headlines for future releases - there will be countless smaller enhancements and features throughout the editor and runtime.

If there’s anything here you’re excited by, that you’d like to get mored involved with, then please do come talk to us - either on the forum or on slack.

Node-RED

Version 3.1 released

Editor Updates

Change notifications on tabs

A bigger workspace

Locking Flows

Hiding Flows

New Group User Experience

Group-level scope for the Catch/Status

Updated Context Menu

Adding images to node/flow descriptions

Mermaid Diagrams

Global Environment Variables

New subflow environment variables

Changes to how Environment Variables are evaluated

Linking to Node Help

Deprecating synchronous access to JSONata

Improved wiring for horizontally aligned nodes

Runtime Updates

Individual http middleware for httpStatic routes

What’s next?

2023 Community Survey

Version 3.0 released

Migrating from Node-RED 2.x

Editor Features

Context Menu

Junctions

Debug Path Tooltip

Continuous Search

Default node names

Monaco Text Editor

Remembering cursor position

Accessing previous welcome tours

Runtime Features

Editing stopped flows

Diagnostic Report

Multiple static folders

Node updates

Dynamic Link Call node

Environment Variables in the Template node

Debug node message count

Predefined HTTP Request headers

What’s next?

Introducing the Node Scorecard

Changing our recommended naming convention

Node Developers

The Future

Version 2.2 released

Highlights

Search History

Remembering zoom/position

Aligning nodes

Detaching nodes

Selecting multiple wires

Slicing wires

Subflow Output labels

Predefined Environment Variables

Node Paths

Node Updates

What’s next?

Version 2.1 released

Highlights

New Welcome Tour Guide

Hiding tabs

Dynamic MQTT nodes

Auto-complete in msg TypedInputs

New Link Call node

Edit & Arrange menus

Flow/Group level environment variables

Other node updates

Debug sidebar options

Deep copy option on Change node

Delay node updates

Join node reset timeout

TCP Request node can return Strings

File nodes renamed

Documentation Updates

What’s next?

Version 2.0 released

Node.js 12.17.x or later required

Auto-complete in `msg` TypedInputs

`node-red admin init` command

Renamed `RBE` node to `Filter` node

Removed `tail` node

新しい`externalModules`設定

Splitting `.config.json` into multiple files

Introducing `RED.hooks` api