🎉 Node-RED 4.0.0-beta.3 released

News
1

:tada: The third and hopefully final beta release of Node-RED 4.0 is now available!

Update May16th: We've republished the beta as 4.0.0-beta.3-1 to fix a packaging error.

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

This release addresses all of the issues that had been highlighted against the previous beta, and throws in some new features. Here are the highlights.

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

  • [node-red/array] Error: range already registered reported in start up - entirely harmless Fixed in 4.0.0-beta.3-1 repackage

Multiplayer Mode - User Presence display

The previous beta introduced the new Multiplayer mode as we iterate towards a better user experience when multiple people are working in Node-RED at the same time.

With this update, we now show where in the editor other users are - which tab they have open and whether they are editing a node.

nr4-multiplayer-location

As before, this new mode is not enabled by default. To turn it on, you need to set editorTheme.multiplayer.enabled property to true in your settings file. We've added a placeholder in the default settings file, but for an existing install, you'll need to add it yourself. You can see how/what it should look like here.

Better background deploy handling

In the same theme as the new Multiplayer Mode, we've also made some improvements to the existing 'background deploy' handling in the editor. This is where someone deploys new flows whilst you are busy working in the editor.

Previously, you would get a notification that you couldn't ignore and would have to interrupt what you were doing to deal with. If your colleague was being particularly productive and deploying frequently, you'd get a new interruption every time.

With this release, we've made the notification less intrusive. It's no longer modal, so you can carry on what you were doing without having to take any action. We've made it slim line so it doesn't get in the way, and it will self-close after a short period. As with similar runtime notifications, we now also show a warning icon in the header if there has been a background deploy - as it will need dealing with eventually - clicking on that icon shows the notification so you can take action when you choose to.

nr4-background-deploy
nr4-background-deploy1080×236 11.3 KB

Improved Diff view for moved nodes

When reviewing changes in the flows, either as a result of a background deploy, or as part of the Projects feature, we now highlight nodes that have only been moved separately to those that have had configuration changes.

When faced with a long list of changes, this will make it easier to spot changes that you care about.

nr4-diff-update
nr4-diff-update1110×286 21.3 KB

Faster deploys for large flows

We've swapped the library we use to clone flow configurations in the runtime. The new library is faster and uses less memory.

The gains are less noticeable in 'typical' flows, but for those of you with large flows, there should be an improvement.

In my testing, a config with a few hundred tabs with a few hundred nodes on each, plus some subflows went from 8 seconds to deploy down to just over 1 second. YMMV.

Other updates

  • Middle mouse clicking on a tab now hides it - similar to most modern browsers - thanks @Steve-Mcl
  • Removed a bunch of code no longer needed due to dropping older Node versions - thanks to Rotzbua
  • Some typo fixes and docs improvements - thanks @zj-flowfuse and @joshuaC
  • Some tidy up of internal apis in the Function node - thanks patlux
  • Better timeout handling when npm takes a while to respond - thanks @hardillb
  • Some updated translations - thanks @kazuhitoyokoi and @GogoVega
  • Better handling of version updates in Projects mode - thanks @kazuhitoyokoi again

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 available under nodered/node-red-dev:v4.0.0-beta.3-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

So we've just missed our goal of getting the full 4.0 release out by the end of April - but we're very close. All being well, this should be the final beta release we do. There are a small number of items we'd like to get in and we'll see if they warrant a further beta release or not.

We should be on track to do the full 4.0 release in the next 2 weeks.

7 Likes
2

Thanks for the work,

I have a palette already registered error:

15 May 18:44:31 - [info] Node-RED version: v4.0.0-beta.3
15 May 18:44:31 - [info] Node.js  version: v20.10.0
15 May 18:44:31 - [info] Darwin 23.2.0 arm64 LE
15 May 18:44:31 - [info] Chargement des noeuds de la palette
15 May 18:44:33 - [info] Dashboard version 3.6.5 started at /ui
15 May 18:44:33 - [warn] ------------------------------------------------------
15 May 18:44:33 - [warn] [node-red/array] Error: range already registered (line:58)
15 May 18:44:33 - [warn] ------------------------------------------------------

I don't have any other palettes with this type of node.

PS: Sorry, at the moment I don't have much time to devote to Node-RED in addition to my school cursus :cry:

3

Yes, getting the same warning. Windows 11.

0|Node-RED | Welcome to Node-RED
0|Node-RED | ===================
0|Node-RED |
0|Node-RED | 15 May 18:07:03 - [info] Node-RED version: v4.0.0-beta.3
0|Node-RED | 15 May 18:07:03 - [info] Node.js  version: v18.20.1
0|Node-RED | 15 May 18:07:03 - [info] Windows_NT 10.0.22631 x64 LE

0|Node-RED  | 15 May 18:07:05 - [info] Loading palette nodes
0|Node-RED  | 15 May 18:07:05 - [info] Node-RED Contrib Theme Collection version: v3.1.11
0|Node-RED  | 15 May 18:07:10 - [info] Worldmap version 4.8.0
0|Node-RED  | 15 May 18:07:10 - [info] Dashboard version 3.6.5 started at /nr/ui
0|Node-RED  | 15 May 18:07:10 - [warn] ------------------------------------------------------
0|Node-RED  | 15 May 18:07:10 - [warn] [node-red/array] Error: range already registered (line:58)
0|Node-RED  | 15 May 18:07:10 - [warn] ------------------------------------------------------
4

Okay, my bad. Something slipped in that shouldn't have. But it is harmless.

2 Likes
5

I get this error when starting the linux/arm/v7 docker version:

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

So far I have not detected any effects. However, the version number in the editor is still 3.1.9.

6

Can you check you are puling from nodered/node-red-dev - the dev stream (4.x) , rather than nodered/node-red which is the stable stream (3.x)

7

I am testing using a DOCKER file to replace the default flow.

The first line is:
FROM nodered/node-red-dev:v4.0.0-beta.3-debian

Just using the default flow causes this error that results in a restart loop:

image
image987×259 8.73 KB

By copying an existing flow (made in version 3), node-red appears to run normally, but the editor looks like version 3.1.9.

8

What version of Node-RED does it report at the start of the log output?

That looks like a fatal error that is stopping NR running. If you can still load the editor in your browser after hitting that, you must have it pointed at a different instance still running 3.1.9.

As for the error itself - that's an odd one as its from the core of Node-RED related to the session handling. Do you have adminAuth configured in your settings file? I can't immediately see a path that would lead to that specific error. Will need to dig into it a bit to see if there's a timing window here.

9

Starting with the default flow logs as starting with the beta. Adding a custom flow file logs as v3.1.9.

10

I'm not clear what you mean here. How exactly are you adding a custom flow file? What command are you running?

11

We've just published a new set of packages for the beta - 4.0.0-beta.3-1. This removes the [node-red/array] Error: range already registered error on startup. No other changes included.

1 Like
12

When creating a custom image based on the beta that replaces the default flow with one exported from v3.1.9, the container starts, but logs as starting with v3.1.9. This problem persists in beta.3-1.

The "getSessions" crash reported earlier occurred when using only the "FROM" line in the DOCKERFILE (i.e. default flow and settings). I don't see how this relates to the [node-red/array] warning, but it no longer happens with v4.0.0-beta.3-1-debian.

FROM nodered/node-red-dev:v4.0.0-beta.3-debian

WORKDIR /data
COPY package.json /data
RUN npm install --unsafe-perm --no-update-notifier --no-fund --only=production
WORKDIR /usr/src/node-red

COPY settings.js /data/settings.js
COPY flows_cred.json /data/flows_cred.json
COPY flows.json /data/flows.json
13

What is in that package.json?

14

That was the issue. The exported package.json file was referencing version 3 and overwrote the version on the image. Changing the version number to "next" now allows running a custom beta image with a flow and settings file created by v3.1.9.

However, I still get this error for both custom and default Armv7 image:

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

However, there do not seem to be any noticeable effects.

15

Correction. The getSessions error persists on Armv7 in beta3-1. Here is a log output from unmodified beta image. Docker version 26.1.0 on Debian Linux.

image
image1312×757 24.1 KB

16

So far I have not been able to reliably recreate the getSessions crash. It has happened several times with a clean, unmodified beta image on first starting the container, but it does not happen every time. I start the container with this command when I am testing:

docker compose down --volumes && docker compose up -d && docker logs root-node-red-1 -f 2>&1

17

The package.json in /data should NOT contain Node-RED in it's dependency list

18

Is the work to complete the support for Dashboard 2.0 widgets in subflow and in subflows packaged as modules to be included in 4.0.0? That is Unable to position a subflow containing a ui-node on the dashboard · Issue #710 · FlowFuse/node-red-dashboard · GitHub and A subflow containing a ui-template, and packaged as a module, does not appear in dashboard config panel · Issue #722 · FlowFuse/node-red-dashboard · GitHub which I understand both need core work as well as dashboard work.

1 Like
19

I'll need to defer to @Steve-Mcl on that; I'm not aware of any further core changes needed in this area.

20

@Colin

I know #722 mentions Node-RED core but the issue i was thinking about was resolved in the next beta.

As far as I can figure (without diving back in), these are things to be handled in the dashboard side. They are raised as issues and will be addressed once @joepavitt schedules them in.

If it turns out it requires a little work in NR core, that would not be a blocker pre or post NR 4 final.

1 Like