I made this post a while back asking about the best way to split up a package of nodes that required a common config node.
I thought I'd solved it by publishing a third npm package that contains the config node. However, it seems that when you add the node (or update v1-v2) through the Palette Manager it doesn't register this dependency as a node.
All it takes to fix it is a restart of the node-RED process and a browser reload. I tested browser-reload-only but it does not fix it.
Before restart of node-red:
After restart of node-red:
I've tested this on both nodeRED v1.3.x and v2.0.2
Is there any way to fix this? Preferred functionality would be to register the auth node without having to restart nodeRED. I haven't registered the auth node with nodered.org (pushlished to npm only), perhaps that will help?
Regards,
-Matt
Edit: project links from GitHub, Primary / User Nodes:
Thank makes sense. Node-RED uses some extra properties in the package.json and I expect these are not processed when something is installed as a dependency. I don't imagine there is a mechanism available in npm to allow this.
Whether you could hack up a post-install script to use the node-red API to register the node I couldn't say.
I'm not sure that I would have approached things that way but without spending more time analysing your code I may be wrong.
Do you really need a config node? Or do you simply need some shared code and configuration? You could simulate something similar to a config node if you didn't need the Editor UI for example.
In uibuilder, I now use two singleton class modules for example and these can certainly be accessed by multiple nodes simply by requiring them. Since all requires are operating within node-red and because they are singletons, you will always get the same instance of the class with whatever code and settings have been instantiated. Of course, that does slightly beg a question about the order in which node-red loads things. But there are likely workarounds for that as well.
Not sure if any of that helps in your case but putting it out there just in case.
The config node is just holding API keys that the nodes use.
What set this in motion was that I decided 6 nodes was too many, especially when I'd developed one that made four of the others redundant. (tl;dr can skip the rest of this paragraph) The redundant nodes were a bit simpler to use (hence the namesake), so I wanted to keep them around somehow. Since these are all "one" project that connects to the same third party API in different ways, it does make sense for them to share the config node so you can use your keys across any of the nodes.
I originally had the same config node defined in both projects, which was fine for me, but it was throwing an error when registering - correctly detecting a duplicate node type. I tried some methods of detecting if the config node was already registered but was unsuccessful. I described those in the thread I linked in the OP.
I'll look at your uibuilder project later to see what I can apply. I'd analyzed the dashboard nodes when working on this before but apparently I need to do more homework.
You only really need a config node if you need to provide a UI in the config node. Otherwise I think that a shared module is sufficient. But there are ways you could do the same thing. For example just show the API keys in each node but store them in a shared module. Of course, you need to store them somewhere as well but a simple file would do that.
Interesting, maybe I'm not understanding. What's a difference between a "config node" vs "shared module", I would probably use those terms interchangeably so there's probably something to learn.
A config node is certainly the standard method and what node-red provides. But a shared module is a standard feature of node.js. A config node has a UI like a normal node and saves its values in the same way as a standard node. Using a shared module means that you take on things for yourself.
Yup, absolutely. However, you don't have a standard requirement
I tried removing the node-red: {nodes: {auth: auth.js}}, entry from my package.json file to prevent Node-RED from registering it as a node. The plan is to load it with require() in my other nodes
In the "Main" node,
I added the line require("my-auth-node/auth.js")(RED) in the main function, and this seemed to register it as a node (comes up in the list of added nodes) but it still wasn't registering on the front-end. I think the corresponding "auth.html" file wasn't getting loaded.
I was thinking about hosting the auth.html on a path using RED.httpadmin and having the main nodes append it to the page, but this is a horribly inelegant solution.
So...
Taking a step back,
All I wanted was to provide the minimal viable set of nodes to users. I personally dislike when a package has a large number of nodes that I never use and they just sit around clogging up my palette. This is why I split up my package in the first place. But I was playing around in the browser console and I made a discovery.
New approach,
I found that there's a function RED.nodes.registry.disableNodeSet() and RED.nodes.registry.enableNodeSet() that seems to cleanly remove and restore any group of nodes from the editor. So I'm going to just add a button to remove the "simple" nodes and store that preference to a file.
tl;dr - I'm ditching the old can of worms for a new one, wish me luck!
