functionExternalModules and module versions

General
1

Having moved to node-red 1.3 I decided to move some external modules I use across to use the functionExternalModules feature.

One of these is js-yaml. Looking in package.json I see that I have previously installed manually version 3.14.0. I removed the require from functionGlobalContext in settings.js and and added it into Setup tab in the function node, removed the global context reference in the function itself and Deployed.

When I ran the function I got an error because it had installed version 4 of the module, which has a breaking change. So I adjusted the code to allow for that and now it works ok. However, if I run, in the .node-red folder,
npm list js-yaml
it shows v3.14.0, but if I go into the externalModules folder and run it, it shows 4.1.0. I can remove the version in .node-red but I think there may be some ramifications to the way this works which may cause confusion.

  1. npm list in the .node-red folder no longer shows the versions of modules actually in use, which is unfortunate.

  2. If I were to upgrade nodejs then I assume that I would have to run npm rebuild from the externalModules folder as well as in the .node-red folder.

  3. Does the install script rebuild in that folder after a nodejs upgrade?

  4. Any backup strategy needs to include package.json and package-lock.json from that folder.

  5. On restoring from a backup it will be necessary to run npm install from that folder as well as from the .node-red folder.

2

I had also missed this. I just assumed they would be added to the package.json in the userDir.

I think it would be better to have an option in settings.js to allow the installs to be in the userDir rather than the sub-folder.

I think that this adds significant admin overheads that anyone not familiar with Node.js will likely miss.

In fact, it might be sensible to add a post-install js script (so it is cross-platform) to Node-RED that warns people of the extra dependencies?

3

There were simply too many problem scenarios to deal with when trying to put them in the main package.json file.

We don't know what the user has manually installed and what has been installed by the runtime as an external module. You'll note there is no UI currently to let the user uninstall anything. That ties back to when we were trying to making it all work seamlessly in the top level node modules. There are simply too many scenarios that resulted in the user removing something they didn't mean to and breaking things.

It was a cleaner solution to keep the external modules used by the flow in a separate location.

Yes there is a slight admin overhead and we need to document etc. But this is also the very first release of this feature so it can evolve and improve with feedback and more contributions.

If you're very interested, I spent a couple hours on one of my weekly live streams agonising over all the issues we faced trying to get into work in the top level package.json - and you can see when I decided it would be cleaner to separate them out.

4

Yes, I can see the sorts of issues involved. Life is rarely simple.

5

Thanks Nick, appreciate the difficulties.

6

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