Docs on "Loading additional modules" outdated?

Via here...

Modules loaded from your settings file must be installed in the same directory as the settings file. For most users that will be the default user directory - ~/.node-red...

If I...
docker run --rm -it --entrypoint /bin/sh nodered/node-red:1.3.5-minimal

Default/home directory is...


Then ls -la (list all contents with details)...


Essentially, despite successfully including some contrib and other npm packages in my package.json, editing settings.json to reference them (successfully) there is no ~/.node_red path.

Is this intended? Are the docs out of date? Is this some peculiarity of the docker version (any idea why)?

It seems like, rather than going the editing settings.json and then global.get route, it would be easier if importing libraries could be done within the function UI (specifically, I am using node-postgres).

Essentially, as per node-red v1.3 (as per the docs), has the workflow been simplified in that merely adding a library in package.json should allow referencing it in the function UI... negating the need to hand-edit the settings.json file?

The docs you link to are for when you are running Node-RED locally.

The docker container uses /data as the Node-RED user directory as described here: Running under Docker : Node-RED

If you mount that externally, as described at the above link, you'll be able to edit the settings file to enable the external modules feature for the function node.

A couple of follow up questions (if I may)... why the disparity in design between "using Node-RED locally" vs using it in Docker (why wouldnt the docker implementation use the same design?) Is there something technically/systemically driving the difference?

So, if in the docker version, what would be the proper way to facilitate usage of referencing external modules via the function UI? Is that functionality hardwired to reference a ~/.node-red vs the contents populated in the /data folder in the docker instance?

Does the function UI method still require editing settings.js to enable them via the functionGlobalContext before they can be referenced in the UI?

A historical choice.

Nothing is hardcoded to ~/.node-red. It uses whatever the userDir property is set to (-u on the Node-RED command line). It defaults to ~/.node-red if not set otherwise.

So as I said, of you mount /data externally as the docs describe, you can edit your settings file, npm install modules etc.

The 1.3 release introduced the functionExternalModules` option: Version 1.3 released : Node-RED

Once enabled (it is currently disabled by default), this lets you manage what modules the function node uses.

After editing settings.json, or only after merely including them in the package.json?

Perhaps I should've been more clear in mentioning, if I can avoid having to mess with settings.json and simplify my docker build, I am all for it :grin:

A historical choice.

Also /data is expected convention for where docker containers should keep this sort of data

You are going to need to update settings.js to enable the feature in the function node, but you shouldn't need to add the modules to the functionGlobalContext if using the new function node capability.

The new external modules feature does not install the modules under the existing package.json. They are installed in a subdirectory with its own package.json file. This isn't an ideal situation, but it is what it is today. We may revisit it in a future release.

I suggest you enable the your settings file (which you must do), then use the editor to add some modules to a function node (as described in the link I sent). Then have a look to see where the modules got installed.

Ah, excellent point/catch/clarification... as knolleary mentioned, "once enabled (disabled by default)" and you helped drive the point, the settings.json will have to be edited anyway (at least once) to override the default behavior.

Thank you both for the answers/clarifications! I'm not sure which to mark as "solution" (and how important it not being marked might be, in this community)

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