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.