Im wondering if you ever had a situation where you needed to have many versions of the same node in a flow.
Hi Allan,
I ran into a similar situation—not because I needed multiple versions of the same node, but because I had to downgrade a node after an update broke something that worked fine in the previous version.
I opened a thread to ask for input, but it seems that managing or selecting specific node versions isn’t very straightforward at the moment.
1 Like
I'm not sure there is an easy way to install multiple version of a node without some serious npm magic. Sounds like an admin bag of worms. I can see pinning a version may be desirable (as @aitor points out) - which can of course be done by hand editing the package.json but not through the UI.
(so no I've never had that situation)
1 Like
Not "many" but certainly more than 1. BUT, only for testing a node's development.
I've never come across any situation where I needed more than 1 version of the same node in a live flow. Only where I've wanted to ensure that I get the same output from 2 different versions of a node or using the same node under 2 different versions of Node-RED. In both those cases, I run up a new instance of Node-RED with the same flow.
In general, I don't believe there is any way to achieve having multiple node versions in 1 instance of Node-RED since that would, at the very least, create a name clash which would not work. Even in raw node.js, I'm not sure you could achieve this either though it is possible to have multiple versions of a package installed by manually overriding the package name (I'm sure I've seen that somewhere, can't remember the details though).
In theory npm can support aliases - so you can install a different version as an alias - BUT only at the nodejs level - so as you say - all that would do is create a name clash at the Node-RED level - and I'm not sure about any sub-dependencies that each would need etc... Seems like a recipe for making things way more complicated rather than easier imho. (But hey people seem to like Kubernetes so ... :shrug: )
1 Like
I have a solution that won't require the installation of many versions of different npm packages, or use aliases. I can solve this problen at runtime with a Factory pattern, I believe. I will create a demo soon!
The runtime wont need any changes. It will come down to how developers author nodes to support multiple versions.
Package Version => Node version
1.0.0 => V1
1.1.0 => V1
1.1.1 => V1
2.0.0 => V1 and V2
At runtime, using config.version, the right object is instantiated inside the registration function. This ensures consumers can keep updating their packages without breaking flows. No changes to the runtime would be necessary.
A preview of the solution
@dceejay @knolleary @hardillb @aitor
Node authors export the versions of their node as an array of classes. The version is defined using an extra static prop in the class.
Node is registered as usual
The runtime is then going to get the right version for that instance during registration
Im going to find a better solution to the way the runtime version is chosen. The example above was just a simplification of the insight.
All these modules can be manually overwritten, or generated by my Vite plugin virtually. Node authors will just need to provide classes for their Nodes. A solution that doesn't require any changes in the runtime.
In the editor, the config node form will have a picklist to chose the version. When changing the version, the config form rerenders if there are changes in its schema.
Visually the node would have to be the same in the palette and in the canvas. The only thing that changes is the runtime implementation.
If a node has 2 versions, each using 2 different versions of a given dependency, then both versions of this dependency must be included in the package.json using aliases
1 Like
