🎉 Node-RED 4.0.0-beta.1 released

:tada: The first beta release of Node-RED 4.0 is now available!

Node-RED 4.x requires at least Node 18.x. We recommend using Node 20

Here are the highlights for this release. We'll be doing regular beta releases over
the next few weeks as there's still plenty to come before 4.0 is fully released
by the end of April.

The Change Log has the full list of changes.

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

  • None yet!

Updated JSONata

I'm putting this first as it is a potentially breaking change.

The JSONata library is used to provide the expression types in Node-RED - a really powerful way of working with JSON objects. With this release we've updated to the new major release of JSONata that comes with a bunch of performance improvements.

But it also comes with a breaking change with how it gets invoked under the covers. We prepared for this in 3.1 by adding a large warning to the log if we ever spotted a node accessing it incorrectly. With this release, that warning becomes an error.

Given we didn't hear a lot of complaints in the 3.1 release about this, either the warning went unnoticed, or it isn't a wide-spread issue. We'll see...

Auto-complete for flow/global and env inputs

Node-RED already has simple auto-complete on msg fields in the editor. We've now extended that to also work with flow/global context inputs as well as the env type for accessing environment variables.

This makes it so much easier to work with these types of properties - being sure you're using something that exists rather than having to switch between different views in the editor to get the names right.

In the case of env vars, it also shows you where the value was set - useful when you have nested groups and subflows which might be overriding a particular value.

The msg auto-complete is still based on a built-in list of common message properties used by the core nodes. There is interest in enabling this to pull completions from 'live' messages seen by the node in question - but that's not currently in the plan for 4.0.

Timestamp formatting

The Inject node has provided the ability to inject a timestamp since the very early days of Node-RED. The value it actually sets is the number of milliseconds since epoch (aka January 1st, 1970). If you're used to working with JavaScript, then this is a perfectly normal way to pass times around. However, it isn't always what is needed and flows end up using a Function node to reformat it in some way.

With 4.0 we've added options to pick what format the timestamp is generated in at the start. Now, formatting times and dates can be a big can of worms of options. So, for this initial release, we've kept it simple by offering three options:


  • milliseconds since epoch - the existing option, just more explicitly labelled for what it is
  • YYYY-MM-DDTHH:mm:ss.sssZ - also known as ISO 8601
  • JavaScript Date Object - the standard Date object

There is scope to allow custom format strings to be set in the node - but we'll see what the feedback is on these new options first.

A better CSV node

The CSV node has had a big overhaul to make it more standards compliant. It turns out CSV has a whole bunch of tricky edge cases that most users don't hit - but if you did hit them you would be stuck.

The new node follows the RFC4180 standard and is also faster - wins all around.

Existing flows using the CSV node will stay in 'legacy' mode until they are modified to use the new parser.

Customising config nodes in Subflows

This one needs a bit of explaining. Subflows are a way Node-RED lets you create a flow and add multiple reusable instances of it within your flows. For example, a subflow may connect to an MQTT broker and do some standard processing on the messages it received before sending them on. The Subflow can then expose a set of properties that can be customised for each instance. In our example, that could be the topic the MQTT node subscribes to.

However, in that example, the MQTT node's broker configuration would be locked to the same broker config node in every instance - and that's something we're solving in Node-RED 4.0.

We're making it possible to expose the choice of a configuration node in the Subflow properties - so each instance can be customised even further.

Another common use for this will be with Node-RED Dashboard - which uses config nodes to set the location of a widget. With Node-RED today, you cannot really use dashboard nodes inside subflows as you end up with multiple copies of the widgets all packed into the same group. With this update, you'll be able to configure the subflow instance with exactly what dashboard group to place its contents into.

This will probably make more sense once we get the docs updated with some more concrete examples.

Node Updates

Here's a list of the various updates made to the individual core nodes.

  • TCP node - when resetting, if no payload, stay disconnected @dceejay
  • HTML node: add option for collecting attributes and content (#4513) @gorenje
  • let split node specify property to split on, and join auto join correctly (#4386) @dceejay
  • Add RFC4180 compliant mode to CSV node (#4540) @Steve-Mcl
  • Fix change node to return boolean if asked (#4525) @dceejay
  • Let msg.reset reset Tcp request node connection when in stay connected mode (#4406) @dceejay
  • Let debug node status msg length be settable via settings (#4402) @dceejay
  • Feat: Add ability to set headers for WebSocket client (#4436) @marcus-j-davies

Check the full changelog to see what else has been happening.

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.x

So on a Pi you'd do:

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

Docker images

The beta images are building as I write this, but will soon be available under nodered/node-red-dev:v4.0.0-beta.1 - with the default image being based on node 20.

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 is the first beta release to get the ball rolling towards the full 4.0 at the end of April.

There are still plenty of changes still being worked on and more to come in the next few weeks.


Working well for me so far, great work!

Just installed docker version and copied my dev environment onto it ... works OK so far

well done

1 Like

Thanks @knolleary. Works just fine here so far.

A minor error in your info post ... docker should be "nodered/node-red-dev:v4.0.0-beta.1" ... the v is missing in front of 4.0.0 :slight_smile:

2 posts were split to a new topic: Node-RED 4.0 beta + Dashboard 2

Hi, not sure if it counts as a bug, but the Split node is now shown with a capitalized name 'Split' instead of 'split'.


1 Like

The type didn't change, it's just the labelling. Which does beg the question, did any of the core types change? I.e. did the types change or just their labels?

No types have changed - that would be a major breaking change and not something we'd ever do without a very good reason and a lot of highlighting in the change log.

Looks like the label got changed in this PR let split node specify property to split on, and join auto join correctly by dceejay · Pull Request #4386 · node-red/node-red · GitHub as it wanted to reuse the Split text inside the edit dialog where it wanted to be capitalised... so an unintentional side-effect that didn't get spotted.

1 Like

Is there a convention to use lower case for palette labelling and types? I've been using CamelCase for a lot my types because of my OOP background where classes are capitalised.

Is there a convention to use lower case for palette labelling and types

It is the convention we use in the core nodes. I don't think we've ever explicitly documented a requirement in this area.

There was a previous request to make URL's case sensitive for v4 given that Socket.IO (used for Dashboards 1 & 2 and UIBUILDER) is case sensitive by default which could lead to hard to track down bugs.

Also, the W3C recommendations are to use case sensitive URL's.

Could this be included?

Is there a PR (or issue) Julian. Please link to there is & I'll take a look & consider implications over the weekend.

Sorry Steve, I raised it ages ago, so not sure. If not, I'll raise an issue - let me check.

Yes, there is:

My main reluctance here is that we've had one issue reported in 10 years on this subject that I'm aware of. Whereas we have no idea how many existing instances rely on the case insensitivity behaviour. That doesn't immediately give me warm feelings over the need to make a breaking change of this nature.

I was very surprised that the pi install script accepted --nodered-version="next" to let me get the beta verson.

bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered) --node20 --nodered-version="next"

Works good so far. Testing on a pi5 8gb. At the very least, my published nodes seemed to work just fine.


Show off :wink:


lol, I waited forever to get my Rpi4 and had it about a month when they announced the 5. I suppose there's no reason not to get another one; they don't take up much space. :slight_smile:


Subflow packaging as a module appears to be broken if the subflow includes a D2 ui-group config node as a subflow property.

Having packaged it up and installed it, on placing it on the flow, Deploying, and opening up the node to set the config all is well, but if I then select a ui-group node, deploy, and then re-open the node I see

oneditprepare b7fa46dd25e31c0d sf:617c00e61edb38f6 TypeError: Cannot read properties of undefined (reading 'sort')
red.min.js?v=3ee9a1d92ab2:18 TypeError: Cannot read properties of undefined (reading 'sort')
    at T (red.min.js?v=3ee9a1d92ab2:18:426526)
    at Object.y [as prepareConfigNodeSelect] (red.min.js?v=3ee9a1d92ab2:18:419769)
    at red.min.js?v=3ee9a1d92ab2:19:133222
    at u (red.min.js?v=3ee9a1d92ab2:19:133291)
    at Object.buildEditForm (red.min.js?v=3ee9a1d92ab2:19:138723)
    at Proxy.oneditprepare (<anonymous>:19:25)
    at t (red.min.js?v=3ee9a1d92ab2:18:422357)
    at n (red.min.js?v=3ee9a1d92ab2:18:423285)
    at Object.success (red.min.js?v=3ee9a1d92ab2:18:423576)
    at c (vendor.js?v=3ee9a1d92ab2:2:28294)
    at Object.fireWith [as resolveWith] (vendor.js?v=3ee9a1d92ab2:2:29039)
    at l (vendor.js?v=3ee9a1d92ab2:2:79800)
    at XMLHttpRequest.<anonymous> (vendor.js?v=3ee9a1d92ab2:2:82254)

The node does appear to correctly picking up the group, but it is not possible to get in to edit it any more.
I can put an example up on github for testing if it is not obvious what the problem is.

I have uploaded an example. It can be installed using
npm install colinl/node-red-dropdown-cdl
It appears as Dropdown CDL in the Functions category. I need to work out how to change the category.

There is also a presumably unrelated issue A subflow containing a ui node, packaged as a subflow, does not appear in dashboard config panel · Issue #722 · FlowFuse/node-red-dashboard · GitHub

There seems to be a problem with the command node-red -u under some circumstances. If I run

cd ~
node-red -u ~/.node-red-1884 -p 1884

Then I see this which is as it should be

30 Mar 14:40:26 - [info] Node-RED version: v4.0.0-beta.1
30 Mar 14:40:26 - [info] Node.js  version: v20.5.1
30 Mar 14:40:26 - [info] Linux 5.15.0-101-generic x64 LE
30 Mar 14:40:26 - [info] Loading palette nodes
30 Mar 14:40:26 - [info] Settings file  : /home/colinl/.node-red-1884/settings.js
30 Mar 14:40:26 - [info] Context store  : 'default' [module=memory]
30 Mar 14:40:26 - [info] User directory : /home/colinl/.node-red-1884
30 Mar 14:40:26 - [warn] Projects disabled : editorTheme.projects.enabled=false
30 Mar 14:40:26 - [info] Flows file     : /home/colinl/.node-red-1884/flows.json
30 Mar 14:40:26 - [info] Server now running at

However if I go into the usual user dir and run it

cd ~/.node-red
node-red -u ~/.node-red-1884 -p 1884

then I see

30 Mar 14:35:15 - [info] Node-RED version: v4.0.0-beta.1
30 Mar 14:35:15 - [info] Node.js  version: v20.5.1
30 Mar 14:35:15 - [info] Linux 5.15.0-101-generic x64 LE
30 Mar 14:35:15 - [info] Loading palette nodes
30 Mar 14:35:15 - [info] Settings file  : /home/colinl/.node-red-1884/settings.js
30 Mar 14:35:15 - [info] Context store  : 'default' [module=memory]
30 Mar 14:35:15 - [info] User directory : /home/colinl/.node-red-1884
30 Mar 14:35:15 - [warn] Projects disabled : editorTheme.projects.enabled=false
30 Mar 14:35:15 - [info] Flows file     : /home/colinl/.node-red/flows.json
30 Mar 14:35:15 - [info] Server now running at

Note that it is picking up the wrong flows file.
I have checked with NR 3.1.6 and it does not show the problem.