NR Solution Design with Debian and Windows using uibuilder, VSC and Parcel

I am in the process of moving NR from a Windows 10 box to a Debian 11 box.

The migration went well with all my NR flows working on Debian 11.

The problem is that I am also using uibuilder (v2.0.8 at the moment) and having moved all my SPA VueJS files across to the new uibuilder folder in Debian and changing the path to "uibuilderfe.js" (node_modules/node-red-contrib-uibuilder/nodes/src/uibuilderfe.js') to it's new location, I am starting to see compile issues from VSC.

I appreciate that this is barely a Node-RED issue, however someone might have a similar setup and I hope @TotallyInformation might have a view.

The aim is to be able to run VSC on my Windows desktop to do development.
I think that all my VueJS files etc need to be on the Debian box as uibuilder is installed on the Debian box.

It would be great to leave all the code on my Windows 11 PC, compile it there an copy the "dist" folder to the Debian box, but I tried that once knowing that there are likely some file path issues, and it failed... or maybe I just didn't do it right. @UnborN - any thoughts? -
Edit1: It does work when I copy the "dist" folder to the Debian uibuilder project location! Nice to know you can do that, but would still require another step each time I compile to test the output - admittedly I could write a simple batch script to copy the code across :thinking:

The options I can see are:

  1. Persist with the compile errors in VSC on Windows 11 and just get it to work - if it's even possible
  2. Investigate VSC remote to see how it works - does it allow me to still use VSC on Windows, but point to the Debian box?
  3. Install VSC and Parcel on the Debian 11 box and then remove desktop into it when I want to do any development in VSC
  4. [Edit2] Leave VSC, Parcel and VueJS files on Windows and then have a manual step to copy the compiled code (ie the "Dist" folder) across to Debian

Option 3 is my least favourite, but probably the least risky one to do.

Hi Alex, hows it going ?

The source files is better to be on the Debian machine .. which is the one running Node-red and uibuilder
You can remotely edit them (seamlessly) with VSCode using a VSC plugin called Remote - SSH

what compile errors do you get with Parcel on the new setup ?
do you have the same uibuilder version 2.0.8 there as with the Win10 system ?

@UnborN

Great to hear from you after all this time.

Would be lovely to do a chat session at some point. I can show you what I've done since we last talked :wink:

EDIT: I'm really getting into Debian and am about to do a massive upgrade on the back-end of my HA setup, would love to talk to you about it.

There are lots of VSC errors and I've changed things around, so the errors have changed.

I just stumbled across the Remote - SSH for VSC as well, but being able to copy the files across seems to also work.

we like errors .. sounds like fun ..what are they ? :wink:

I have the same workflow. Dev on W10 and deploy on Debian.

If your uibuilder files are in the default location then if you've copied your ~/.node-red/ userDir folder, you've already copied your uibuilder files.

I use VSCode remote SSH to edit my live uibuilder front-end code files and use it all the time. But you can certainly copy them over manually. Or even use GitHub or similar source control if you really want to. Generally, the uibuilder websites on my home automation server aren't terribly complex. I'll sometimes do a quick tweak using uibuilder's editor but mostly use VSCode remote editor.

There is nothing special about uibuilder's front-end code, that is one of the points of uibuilder - that you can use standard web development tooling.

@UnborN helped me set it up SSH from VSC tonight. It's working like a dream!

I say that, but it was quite challenging getting parcel to work on Debian. Lots of manual steps, but it's working at last.

We spent a lot of time then with a socket.io error. The connection worked on your vanilla uibuilder node, but not on the SPA setup I have.

In the end we found out that v2.0.8 of uibuilder installs socket.io-client. v4.1.4 of uibuilder then removes it, but there is a line of code in one of your files (jn v4.1.4), uibuilderfe.js I think, and it still references socket.io-client, despite it no longer being present.

[EDIT] this is the code from uibilderfe.js from v4.1.4 of uibuilder:

// @since 2017-10-17 CL: tell webpack that we need socket.io client if running from webpack build
if (typeof require !== 'undefined'  &&  typeof io === 'undefined') {
    // @ts-expect-error ts(2307)
    var io = require('socket.io-client')
}

It can be found here: \node-red\node_modules\node-red-contrib-uibuilder\front-end\src

To fix it we manually installed socket.io-client and it worked!!

No idea what was going on. I'm pretty sure it had something to do with my setup.

[EDIT] I wonder though on second thought, whether the code above should be changed to reflect that socket.io-client is removed in v4.1.4 (and presumably in earlier versions of 4.x).
I suspect I may open a can of worms up here, as admittedly this is way over my head and the code above may not actually relate to the issue. Further testing of changing:

 var io = require('socket.io-client')
to
 var io = require('socket.io')
or something else

Would prove that it's that line of code calling socket.io-client, but I've run out of steam.

Apologies in advance and Merry Christmas!!

Ah, interesting. That was added by someone else early on in uibuilder's career in order to make the fe code compatible no matter which way you load and execute it - e.g. either directly or via a build process. I'll admit that I don't fully understand it all myself. I'd not spotted that the client name had changed so a good spot there.

I'm away with family at the moment - when I get back I'll try to add a proper fix.

Thanks for the Christmas gift :smile: Have a good Christmas. J.

Team effort, you can thank @UnborN as well, who spotted the code.

Merry Christmas to you too!

1 Like

Merry Christmas guys,

Why var io = require('socket.io') .. wouldnt that point to the socket.io server library ?
maybe try to change it to var io = require('./../../../socket.io/client-dist/socket.io.js')

I'm not at home to check on my dev PC at present. I'll do some tests when I can. I think that ./../../../socket.io/client-dist/socket.io.js' might be a little too specific. It might not work on all installations?

You could check the package.json file for socket.io to see if it has a "browser" property which I think that parcel/webpack may use to identify the correct front-end library. If it does have one then Alex's entry is probably correct. You would soon know anyway because I don't think the server js would work in the browser.

Hi Alex, can you please share your Parcel config so that I can look at this in more detail?

Also, if you have time, you may want to try the vNext branch from GitHub since. Don't think that will change what you are seeing because vNext doesn't have a lot of changes in the front-end but the back-end is extensively re-written.

OK, I've worked out what the code in uibuilderfe is actaally wanting now. As I said, it was provided by someone else.

Confusingly, socket.io-client is provided by a separate npm package: socket.io-client - npm

So to get Parcel or Webpack working with the code as it stands, you need to install that as a dev dependency in the folder you are using as the root for your Parcel/Webpack project. Please make sure, though, that you are using the same version as the version that uibuilder is using because there have been cross-version problems in the past.

Personally, I strongly recommend NOT putting the Socket.io client in your bundle. The way it is packaged seems to mostly expect that you will load it as a script resource separately. That will also ensure that you always have the correct version. There is really very little, if anything, to gain from bundling it with your own code, especially with modern browsers that are so much better at sensibly loading resources efficiently.

I will add a comment to the next release of the fe code to indicate what is needed.

1 Like

I'll PM you on that point.

1 Like

You may be interested to note that I've just been updating some uibuilder documentation. In the process, I've stumbled upon the method needed to use the dev servers in build tools along with uibuilder. :sunglasses:

I used Snowpack for this as it is so simple and I already had some documentation on its use waiting to go live.

I note that using Snowpack, I had no issues with the Socket.IO client library. Everything "just worked". Well, it did once I worked out the magic combination of settings anyway!

If you have the vNext version (updated this evening) of uibuilder installed, open the Tech Docs and look at the page titled "Optimise & Transpile (Build)". That also has a link to the Snowpack documentation.

1 Like

I installed the latest version of vNext and read the Tech Docs .. very useful information.
Interested to know about the Snowpack plugin you used @snowpack/plugin-vue
did that compile Vue2 also or was your project a Vue3 app ?
do you have it on Github by any chance ?

i was trying to get something online for a uibuilder vue navigation bar template .
you can read some info for it or try it out if you have time (link)

sidenote: i noticed with the Tech Docs that the sidebar doesnt show in the vNext version .. do you get the same ?

I believe that the @snowpack/plugin-vue one compiles to v3 - that might have been why I had a few issues! There is an alternative [@morgul/snowpack-plugin-vue2](https://github.com/Morgul/snowpack-plugin-vue2) that compiles v2. My recent messing was done without any framework just to keep things simple.

I've still some more experiments to do with Snowpack. I believe it will be possible to configure and code things so that you don't have to mess with the changes to links and the start parameters. I don't have time right now to play too much but I'll come back to it at some point.

Every time I come back to Snowpack, I'm more impressed.

Thanks, I'll try and find some time to have a look. Though of course, I've taken myself down a new uibuilder rabbit hole now as I've started to build a long-delayed addon node for uibuilder that will do caching. Might not make it live into v5 :slight_smile:

There's a good reason for that :wink:

It only uses uibuilder as a static page loader!

It uses Docsify to do all the clever stuff so uibuilder only has to make the single docs/index.html page available. Everything else is loaded dynamically via CDN's. That's so I don't have to have 2 different versions because the same docs folder also provides the live GitHub web site at https://totallyinformation.github.io/node-red-contrib-uibuilder/#/.

I love Docsify for building documentation sites. Here's another one of mine, this time done for work: NHS England and NHS Improvement IT Standards.

1 Like