Hi, I use a different user folder than .node-red without problem. The only issue I'm not able to solve is the node_modules folder. Following other topics I created a simlink to the one inside the .node-red folder installation but it doesn't seem to work.
I copy all folders and files but node_modules from .node-red to my new_folder
I create a sim link to node_modules inside my new_folder
When I run node-red as -u new_folder, the nodes already installed are missed.
There is a way to specify in settings.js the node_modules folder to use?
Thanks a lot
Hi Colin, I mean I would like to have just one folder where to have all the nodes installed. So even if I run more istances, installing a new node from them, it will be installed always in the same folder and I will have it available for all the instances (after restart them of course)
Regarding userDir, if I'm not wrong it is used as directory even for credentials, contexts and so on. If i modify it, calling node-red with the -u option do I still have all this staff dedicated in each "-u directory"?
Summarizing I would like to have:
a folder for each instance with its flows, credential, context, ecc;
a sigle directory for all node installed usable from all the instances;
I think if you use userDir to specify the directory, then in that directory, make package.json, package-lock.json and node_modules be links to the master ones then you should get what you want. I haven't tried it though.
If you add or remove nodes in one of your instances you will need to restart all the others to get them to see the changes.
Thanks. Unfortunately I cannot try it since I'm encountering another problem and I cannot install / update any nodes anymore. Now even the original flows doesn't work any more because doesn't find some nodes so it get blocked. I just started a new topic in order to avoid messing
Having a single, central node_modules folder should work, you just use filing system links.
However, you will then have to manually update the package.json file in each userDir. It is not recommended.
What you could do instead would be to do a local install of Node-RED rather than a global install. Then you can easily install common nodes into the Node-RED folder. Each instance that is run from that install (you have to specify a different userDir when running of course) will have the same nodes and the users will not be able to uninstall or update them. You have to remember to update them yourself from the command line (or via a simple script). My alternate installer (see GitHub) shows an example of how to install Node-RED locally.
Thanks a lot. For local installation I need to look at it when I have a bit of time to carefully try it. At the moment a quick solution could be link back package.json and package-lock.json. They are simlink, (Harfd link in windows), exactly? What do you mean i have to manually update them?
Windows (NTFS) supports hard and soft links as well as junctions. It is generally safer to use soft links as they are translated across filing system boundaries.
If you aren't linking the package.json then each instance will have its own. You can use one instance to install a new node but though the package will exist in the linked node_modules folder, the other instances will not have it in their copies of package.json and so those instances of node-red will not load them. You would have to somehow update the dependencies list in each package.json file (and should probably just delete the package-lock.json as it isn't relevant in that case). Obviously you could have a script to copy from a master install to the other instances. And don't forget to restart node-red after changes.
I made some test and at the and I'm going to summarize it, hoping will be useful to the others.
main folder: .node-red (installation patch)
settings.js as it is (no change for userDir)
my_folder (new folder containing my node-red project. (running node-red with the option -u .....\my_folder)
create junction to .node-red\node_modules with the command mklink /J (as administrator)
create hard link to .node-red\package.json with the command mklink /H (as administrator)
From now on:
all the nodes must be installed from the main instance, the one simply running with node-red command
the "my_folder" node-red instance must be restarted in order to update the new installed nodes
the package.json inside "my_folder" apparently doesn't came update (if you open it won't see the new ones) but actually it's node-red instance will find all new nodes and works perfectly.
Of course it would be better to update it as the others suggest
Don't to try to install/update nodes from the "my_folder" node-red instance. In this case the link to .node-red\node_modules will be broken (I don't know why), and you cannot install/update any nodes any more.
At this point, a part for the nodes, can someone tell me which are the files/directory to backup?
I think they are all but: node_modules (directory), .config.nodes.json (file). Is that correct?
Even to me it's quite strange, But that's it. I made several test and I get always the same. The file ....\my_folder\package.json seems not to be update with the new installation (even looking at its details or opening it) but if I run node-red -u .... \my_folder, I can see and use them, and of course I find them inside manage palette, too.
Honestly I cannot explain this behavior!!
As I said maybe someone else more expert than me can performed more test.
The first one (package.json inside my_folder dir) is an hard link created with mklink /H command (I tested it again and again)
If I delete the my_folder/package.json it's created again without any node inside, but node-red see all the nodes installed with the main instance (So it seems to be required but not used)
I do want to be able to install nodes from the second instance, too (having them in all the others as well), but I'm not able to do it in any way, even following the posted instruction. At the end this is the compromise I had to accept to have more instances all updated with the same nodes installed, but just upgrading by one instance (the main one)
I don't know anything about links in Windows, but if there are the same as in Linux then a hard link will not do it. A hard link means that the second one is a direct reference to the sectors on disk. The result is that if the original is, for example, deleted then the fact that the second one still references the space on disk means that it will not be deleted but will still exist for use by the second link. It has to be a soft link.