Node-RED node installed as dependency requires restart

I would like to install common Node-RED "support nodes" as a dependency of other Node-RED nodes I'm developing. I've confirmed that a dependency node is installed when installing the dependent node via the palette manager, but Node-RED has to be restarted for the dependency node to be available, just as if I had run npm install manually.

Is this a design choice, or is it just because the dependency is installed by npm in the background, and Node-RED doesn't know about dependencies? Should I bother to make a feature request for Node-RED to detect such modules and load them without a restart?

Btw; I read through all the (seemingly relevant) posts yielded by a search for "dependencies" under reating Nodes before posting this.

Edit: After a quick look at the code, I can see that Node-RED at least knows about dependencies... Not yet sure what it does with that knowledge, though.

Can you provide an example of what you are asking about here?

A link to the node you are developing so we can see the package.json

And how are you seeing the problem, is it throwing an exception due to not being able to find a node?

EDIT:
OK, I think I've worked out what you mean, this will because NR only scans the explicitly installed package for nodes, not a full rescan of the node_modules directory. This scanning has a reasonably high overhead which is why it is directed.

This would introduce the possibility of meta nodes, that just pull in a collection of other nodes, but also begs the question to if your nodes really need to be separate or are the dependencies 3rd party?

There is an item on the backlog that covers this and explains why it doesn't work today.

They don't need to be separate, but it seems tidier to publish them separately than bundled together. So, say nodeA and nodeB both can use a postProcessNode. If I publish nodeA and nodeB separately, my options are then either:

  • include postProcessNode in both packages.
  • publish postProcessNode as a separate package.

If published separately, it would be nice if it didn't have to be manually installed.

Anyway, when a node is installed from the palette manager, it's immediately added to the palette. I figured the installation logic could do whatever happens there to the dependencies as well (if appropriate).

Now off to read the linked backlog...

Edited for clarity
(and for spelling)

Huzzah, I think it works! Still requires a browser refresh, but that's much better than a restart.

I had found some code for loading dependencies (in loader.js - addModule()), but I never saw any output from this debug line:

log.debug(`Loading dependencies for ${module}`)

Digging further, in localfilesystem.js - convertModuleFileListToObject():

        if (moduleFile.package['node-red'].dependencies) {
            nodeList[moduleFile.package.name].dependencies = moduleFile.package['node-red'].dependencies;
        }

So node-red/dependencies, not the root (npm) dependencies.

From a 2017 comment in the backlog (Allow node modules to have node modules as dependencies · Issue #569 · node-red/node-red · GitHub):

Is there any way to declare node-red-node-dependencies.
Perhaps in the package.json. Something like this:

"dependencies": {
    "nodered-node-serialport": "^0.0.1"
},
"keywords": [ "node-red" ],
"node-red"     : {
    "nodes": {
        "sample": "sample/sample.js"
    },
    "dependencies": {
        "nodered-node-serialport": "^0.0.1"
    }
}

I'm guessing node-red/dependencies was just speculation at this point? Anyway, I found a reference to it in the docs for Packaging a Subflow as a module, confirming my understanding of the code from localfilesystem.js, and gave it a try. Found the commit for the dependency handling in loader.js - Handle subflow modules with their own npm dependencies. So the feature was added for a different use case, but unless there's plans to drastically alter (or remove) it, I guess it's OK to use it for this as well?

It would be nice if the dependency nodes were visible in the palette without a browser refresh, but that'll be a problem for another day.

Edit: added a couple of lines from the backlog comment