Cannot load widgets that are part of pre-installed nodes

[theotherwillembotha]

Current Behavior

Currently I package an instance of nodered as a docker image with some nodes that are installed during the build step. The base image is nodered/node-red:3.1.11 and the preinstalled nodes are added to /usr/src/node-red/package.json. The reason they are added to /usr/src/node-red/package.json is because package.json in the userDir is overwritten when the image is run as a container and the RED.settings.userDir (in this case /data) is mounted externally.

• The preinstalled nodes work correctly in the flows.
• Nodes installed through the pallet and installed via the commandline work correctly (as they are added '/data/package.json')
• Thirdparty Widgets of nodes installed at runtime work correctly.
• Thirdparty Widgets of nodes installed at build time show a 'No Vue component found for ', widget.type, ' - falling back to ui-template' message in the browser console.

I chased the issue down to ui_base.js line 90 (working off branch main commit id 97de583) where the third party widgets are loaded. In addition to the RED.settings.userDir, it looks like you also have to scan the package.json file in process.cwd() for widgets.

Expected Behavior

Thirdparty widgets of nodes installed in the main package.json file should work the same as packages widgets of nodes installed at runtime.

Steps To Reproduce

1. in the root nodered folder, run npm install ........ to install a node that contains a third party widget.
2. verify that the node was installed in the package.json file
3. run nodered and specify the `--userDir' to another folder.
4. verify that node with the thirdparty plugin is not installed in the package.json file in the --userDir folder.
5. create a dashboard with the third party widget.

Environment

• Dashboard version: 1.14.0
• Node-RED version: 3.1.11
• Node.js version: v18.20.2
• npm version: 10.5.0
• Platform/OS: docker
• Browser: frefox 123.0

Have you provided an initial effort estimate for this issue?

I can not provide an initial effort estimate

[theotherwillembotha]

Additional Information:

The current version of our docker build script looks something like this. As mentioned previously, we build an image that contains roundabout 70 of our own plugins and about 10 public plugins.

FROM nodered/node-red:4.0.2-20
USER root:root
RUN apk update
RUN npm install -g typescript
RUN npm install -g vite
RUN chown -R 1000:1000 "/data/.npm"
USER node-red:node-red

# install the "patched" node-red-dashboard.
COPY --chown=node-red:node-red $PWD/node-red-dashboard /nodered/plugins/node-red-dashboard
WORKDIR /nodered/plugins/node-red-dashboard
RUN npm install
RUN npm run build
WORKDIR /usr/src/node-red
RUN npm install /nodered/plugins/node-red-dashboard

# install one of our own widget plugins here.
COPY --chown=node-red:node-red $PWD/plugin_devicemanagerwidget /nodered/plugins/plugin_devicemanagerwidget
WORKDIR /nodered/plugins/plugin_devicemanagerwidget
RUN npm install
RUN npm run build
WORKDIR /usr/src/node-red
RUN npm install /nodered/plugins/plugin_devicemanagerwidget

# run build script using
# docker build -f DockerFile -t nodeconductor:latest .

I left out the parts where we install nodes from the main repo and the rest of our plugins and widgets. We host the container behind a reverse proxy, so the simplest way to test it is usually to just spin it up with

docker run --rm --name dev_nodeconductor -v $PWD/volumes/conductor:/data  --network dev nodeconductor:latest

By not installing the plugins in the /data folder, it allows us to keep the preinstalled plugins versioned by the docker image rather than the user data which makes rolling our plugin versions forward and backward a lot simpler.

[phedders]

I've hit this problem with the dashboard-2-ui-tabulator plugin. Did you find a good workaround?

[pakerfeldt]

I ran into the same problem for much the same reasons as the reporter. I run Node-RED in Docker and my Dockerfile allows me to more conveniently determine what plugins and versions to use, knowing that I can easily re-construct the same runtime.