🎉 Node-RED 3.1.0-beta.2 released

:tada: We have now published the second beta release of Node-RED 3.1.

Node-RED 3.x requires at least Node 14.x, but that reaches end-of-life in a couple months. These days you should really be using Node 16 at least or even 18.

Having considered 3.1-beta.1 to be pretty complete, we've managed to squeeze in a few new useful features.

The Change Log has the full list of changes.

You should also checkout the 3.1.0-beta.1 release post if you haven't already seen what was in there.

And don't forget the Community Survey is still running. Don't miss your chance to share you views on the project and help shape what we do.

Note: if any issues are reported against the beta, we'll update this post to list them here. If you hit a problem, please do check back here before adding a comment.

Known Issues

  • Search button in palette popover only works once - now fixed in git
  • JSONata Expression tester - now fixed in git

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.

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

Oh, and one more thing...

If you hold down alt whilst dragging a selection of nodes inside a group, you can drag them out of the group. Cool huh?

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.

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.

Node Updates

There are a few bug fixes in the core nodes with this release.

One to highlight is a fix to the Join node, where it was leaking memory when in automatic mode.

Be sure to read through the Change Log to see what else is in there.

Installing the beta

If you want to try out the beta, you will need specify node-red@next when you use npm to update. Without the @next you'll still get 3.0.x

So on a Pi you'd do:

sudo npm install -g --unsafe-perm node-red@next

Reporting problems

If you hit any problems, please report them either as a reply on this topic, or in the #core-dev slack channel. Please do not post new topics to the forum regarding the beta as that could confuse users who are not using the beta.

Outstanding work

This has been a reasonable productive beta, clearing off quite a few older issues from the backlog. We'll try to keep that up and address more issues in time for the final 3.1 release.

But we do want to make sure this beta gets a good run through by the community. The UX changes around groups, the change notifications on tabs as well as the features from beta.1 could all do with some community effort to make sure all of the edge cases have been flushed out.


Nice work!
Are you planning to have a docker image for this beta?

They are on their way....


Argh! What a dummy! :grin:

Thought I'd immediately found a bug when double-clicking on a node in a group - of course, I had already tested out the flow lock! :flushed:

A nice set of changes as usual, thanks Nick.

Phew, thank goodness I'd already got my head around that! Bit of a baptism of fire but in the end, I came up with a standard function that seems to work for me.

Ah, unexpected. When you lock a flow tab, it locks the input buttons on inject nodes. Understandable I suppose - just not what I was hoping for.

I kind of remember that this was already the behavior seen in 3.1b1 - yet is this really what we want to get?

Enabling / disabling the button of the debug node might/should/could fall under the lock (as this as well triggers a change state), but the inject node button should not - from my PoV.

This immediately raises another question then: Who shall decide if a button falls under the lock - or not. My vote: The designer of the node...


Docker builds of 3.1.0-beta.2 available here


Including new Debian Buster Node 16 based build (not on s390x or ARMv6 as no base build to use, may move to bullseye as that does include s390x for the final release).

Please test all


Wondering why it's in the footer?
Wouldn't a more natural place be at the top, alongside 'properties', 'description' & 'appearance'?

Those are tabs within the same edit dialog. Whereas this new button opens up the separate help sidebar. So I think mixing the two would potentially be confusing.

I am considering changing the icon to be a more widely recognised one for 'help', rather than the book icon that implies documentation... will see what the feedback is.

1 Like

Or perhaps, in the right top, or even a big button.

1 Like

Would prefer it if it wasn't in the button header as it would clash with this:

Footer is OK for me - though I wouldn't mind both enabled and help to be in the node title header. Would prefer to have them both in the same place either way.

You could always remove your 'docs' button :wink:

We have to consider the wider usage, rather than it depend upon one user case.
(As discussed here - Help button in node properties - #4 by knolleary )

I did say "prefer". :slight_smile:

Those buttons are a significant usability boost for people using that node but they've only just been added, they can always be moved but they do look good there :grin:

I'm finding some 'oddities' when trying the new 'search'.
In Safari, the 'search' icon does not work for the inject node
while in FireFox and Chrome, it works once.

  1. hover over the 'inject' in the left sidebar after a moment the popup appears
  2. click on the search button and a list appears
  3. click somewhere else and the search and list disappear
  4. try to repeat this action and the search never shows up
    If you refresh the page it works again...once.
  1. I see the same issue as @zenofmud on Firefox, WIndows 10.

  2. [quote="knolleary, post:1, topic:76192"]
    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.
    If the help sidebar tab is active, it automatically shows the help for a selected node type. So this button, added to every node config, does exactly the same thing as clicking on the help tab. Or am I missing something?

Perhaps this behaviour could somehow be tweeked so we can see the help for one node type while editing the node wired up to it (to assist matching outputs with inputs)?

Yes. However that is only useful if the user knows the help tab is there, and there is no direct link between the two.

Adding the button gives the user a more direct connection between the two.

Given some 3rd party nodes had started to unilaterally add their own button to do this, it meant they were introducing an inconsistent user experience. So it made sense to add a standard button so users have a far more consistent experience.

Paul, if you refresh, does the "search" button work again?

I have found it works only the first time...


Well OK but once you have clicked a node config Help button, the help tab is open,
Now clicking on another help button does nothing, the help is already shown, So a user might reasonably conclude that the help button is inoperative.

Interesting. I'd never even used that feature! But can confirm that, unsurprisingly, Edge does the same. No errors in the console or log.

Yes. Once.

I realised that it is possible that this button is also being misinterpreted. It does not go to the help sidebar like the newly added help icon does. It goes instead to uibuilder's built-in full documentation.