Node-RED 2.0 is now generally available for everyone to use!
Thanks to everyone who tested the beta releases and provided feedback.
Full details of the release are available on the blog:
Updated docker images will be arriving later today.
22 Likes
node-red admin init is a great idea, and makes it a much easier setup, especially for new users. 
Docker images have been built and published to dockerhub.
4 Likes
The theme collection is also available for Node-RED 2.0.
3 Likes
None of the modules imported by the function node are working on my two Node-RED instances.. Worked perfectly in 1.3.5. I have verified that functionExternalModules is set to true. It seems like the modules are not getting downloaded into the new directory for modules.
The instances are running using the :latest docker-image.
@get_joe hmm , yes, I can see an issue. Investigating...
@get_joe Node-RED 2.0.1 has been published. Docker images building at the moment.
This was a bug I introduced last week and failed to spot relating to how we load modules in the Function node. I failed to spot the modules I was testing with had named exports so behaved slightly differently to other modules without named exports.
One of the unwritten laws of semantic versioning is that any release ending in 0 does not survive more than a couple of hours.
5 Likes
It's true. But the goal of the extended beta periods is to minimise the chances of that happening.
Sadly its a change I made since the last beta that broke things. Mea Culpa.
6 Likes
That resoled most of my issues, but some modules still wouldn't get downloaded. See the error code:
20 Jul 16:41:43 - [error] [function:b3cafeef.b6674] Error: Cannot find module '/data/node_modules/moment'
NoderedExt | Require stack:
NoderedExt | - /usr/src/node-red/node_modules/@node-red/registry/lib/externalModules.js
NoderedExt | - /usr/src/node-red/node_modules/@node-red/registry/lib/registry.js
NoderedExt | - /usr/src/node-red/node_modules/@node-red/registry/lib/index.js
NoderedExt | - /usr/src/node-red/node_modules/@node-red/runtime/lib/nodes/index.js
NoderedExt | - /usr/src/node-red/node_modules/@node-red/runtime/lib/index.js
NoderedExt | - /usr/src/node-red/node_modules/node-red/lib/red.js
NoderedExt | - /usr/src/node-red/node_modules/node-red/red.js
Ended up going into CMD and doing an NPM install due to the modules were present in package.json.
Great work! The only error I get was from the sqlclient-node which was fixed with npm rebuild.
I'm really grateful about the quality of your work!
Thanks, Alex
I'm getting the following two errors for each function node which used external modules in my Windows Server 2008 environment... it's working fine in my macOS environment.
"Failed to load module : Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'"
"Function node failed to load external modules"
1 Like
Try taking out the c:? I can't offhand remember the actual format for including a drive letter in URL format. I seem to remember that there is one. But if you only have a c: drive, it doesn't matter. Use POSIX style instead.
@dudleyjosh interesting. Turns out Windows does behave differently to other OS. We're falling foul of https://github.com/nodejs/node/issues/31710
@TotallyInformation it's internal NR code that is generating the absolute path to the module - where we ought to be then converting it to a file:// url for complete cross-platform compatibility.
1 Like
I've been previously running beta, and really enjoyed being able to add packages in the function node, I've tried quite a few, and which have been added to the .node-red/externalModules folder.
But because the external modules are not automatically deleted when they were no longer used, I was intending to manually delete the majority, and just keep the odd few that I need.
Having just updated to v2.0.1, it appears that now, the external modules listed in the .node-red/externalModules folder have been copied across to the main .node-red/node_modules folder, with the prompt to now delete .node-red/externalModules.
As they are all mixed up together in one folder it makes it more difficult to distinguish packages which are currently being used, and those that are not.
Probably my own fault for not reading the release blog, but I wrongly assumed that new features wouldn't be added after the final beta.
It will only have reinstalled the modules that your nodes are actively using.
If you want to see a list of what it has installed, we keep a list in ~/.node-red/.config.modules.json
I'm up and running using the old GlobalContext for now... so it isn't a show stopper for me. Just wanted put it out there incase it was an actual issue that needed addressed.
Ah, OK. That thread seems to have a viable answer though.
Windows non-POSIX drive specs have always been a bit of a pain. Doesn't translate well to a URL scheme. I blame Bill Gates! 
1 Like
That's good news, thank you.
If that is the case, will externally loaded modules now be routinely deleted from .node-red/node_modules when not required, similar to other node dependencies?
No. We don't remove modules. We will provide a UI feature at some point that helps you manage them.
3 Likes
