Same Node_modules directory for multiple instances of node-red in a PC

How can I use same node_modules directory to use the contrib nodes in separate instances of node-red.
I have 3 instances of node-red running in a PC as windows service, by using NSSM.

the only issue i am facing is that i have to download the required contrib-nodes through pallet manager through each instance of node-red. how do i setup so that i dont need to download them separately into respective folders ?

below is the command line used for setting up 2 different folders/instances.
where am i doing it wrong ?

nssm install NR-DB "c:\Users\\"%USERNAME%"\AppData\Roaming\npm\node-red.cmd"
nssm set NR-DB AppDirectory "c:\Users\\"%USERNAME%"\NR-DB"
nssm set NR-DB AppParameters "-u c:\Users\\"%USERNAME%"\NR-DB > c:\temp\nr-DB.log"
nssm set NR-DB Description "DB Logging"
nssm install NR-LIVE "c:\Users\\"%USERNAME%"\AppData\Roaming\npm\node-red.cmd"
nssm set NR-LIVE AppDirectory "c:\Users\\"%USERNAME%"\NR-LIVE"
nssm set NR-LIVE AppParameters "-u c:\Users\\"%USERNAME%"\NR-LIVE > c:\temp\nr-LIVE.log"
nssm set NR-LIVE Description "LIVE Status"

If you install them globally (using npm -g install ...) then they will be available to any instance.

1 Like

Got it working. Thanks.
Follow up question: Are there any pros or cons of having a global install (of both node-red and contrib nodes?)

Pro: everything has access to it.
Con: everything has access to it.

1 Like

possible con: changing it in one flow may cause other flows to have an issue until you redeploy them

Do you mean upgrading a node? That should not be an issue I think. The upgraded node will not be used until node-red is restarted.

Globally installed nodes may have more access to the system than is wise. This can open unexpected security issues.

Also, they can be hard to track down if you ever need to, the global folders are in weird (I think) positions that are quite different on different OS's.

As nodes are generally written to be locally installed to the userDir folder, they are probably not well tested as global installs. This can occasionally result in weird, hard to track down bugs.

1 Like

How does that work? I would have thought that once node-red loaded the node into memory it wouldn't make any difference where it was loaded from.

Not exactly hard, though you do need to know how to find them.
npm list -g <node-name>
should tell you where the node_modules folder that contains it is.

Can you give an example of where it might make a difference at run time? I am not saying you are wrong, just that I can't immediately see how it might make a difference. Possibly something to do with paths I suppose.

Because the modules are installed to a root accessible area, any inherent low-level weakness (probably in node.js) could allow access to areas of the OS that they should not have.

Which is fine if you are an expert, but a PITA if you are a novice as many Node-RED users are. That is, after all, one of the main benefits of Node-RED.

I don't know that I have a direct answer. However, take the recent discussion about node-red-context-monitor that requires knowledge of where another module is. While we did eventually find a robust way of doing this, if assumptions are made about relative locations of files, this might not hold true when installed globally. In that case, it was the opposite issue, it was assumed that Node-RED was installed globally but that isn't the only case.

In my own code, I have several places where a node needs to be able to manipulate the filing system and in some cases it took many iterations to get it right, often edge cases being discovered by others.

Enough examples anyway to make me nervous about how stable some nodes might be even if it should be a rare issue. A lot of time then has to be spent tracking down the problem because the author rightly assumes that the package will be installed in a particular way.

All good points as usual.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.