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"
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.
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.
