Node-RED Node development in Node-RED?

Share Your Nodes
1

Hi There!

I know that there will be other solution and whatever, however one of the most annoying things about Node-RED is the way the node development is done: outside of Node-RED. This makes creating nodes unnecessarily complex. What I wanted to do was be able to develop, test, publish and commit my nodes completely in Node-RED.

I had a quick play around with Node-RED editor and discovered that to install new nodes, there is this .tgz upload in the palette manager. This flow utilises that to install nodes dynamically into Node-RED via a flow - in this case a node that creates tarballs.

What else? Well a node needs to have a GItHub repository, so this flow pushes new commits to a nodes github repo from within Node-RED. But to have my nodes available within Node-RED, I need to publish them to npm, well this flow does that too. About the only thing this flow doesn't do is press the update node package at flows.nodered.org - who knows whether there is an API for that.

So now I can develop my nodes in Node-RED and not worry about using Emacs to extend Node-RED, just as I don't use Node-RED to extend my emacs.

Hope it helps!

P.S. nothing is perfect that was developed in a lazy afternoon, so don't worry if it doesn't work. The idea is clear.

2

Its an interesting idea. But, to be honest, I don't find that not developing in Node-RED itself to be the most annoying part of developing nodes. Not by a long way.

The complexity of the html file which makes development and linting hard. The fact that the html file and the node.js runtime file have to be in the same folder which causes issues with linting. The complexity of some of the Editor parts - especially typedInput. These are all, in my view, annoying complexities.

The inability to start moving to ESM from CommonJS and the requirement to have to restart Node-RED when you make changes to a node's runtime and reload the Editor when you've made changes to the html file. These are all annoyances too.

Or perhaps annoyances is a bit strong - complexities at least.

Also, npm publishing is not needed for developing, only for publishing. Node-RED can run nodes from local installs or from GitHub installs of course.

I think those updates are manual because there was an issue with the automation?

:rofl: Old school! :wink:

VScode, being node.js native, is a great fit for node development.

Personally, I develop using VScode with my dev instance of Node-RED running under PM2 with its watch function to automatically restart when changes are made.

I split the html file into the component parts and use a running gulp script to automatically update the html file on the fly.

For the runtime, I have a more structured layout of functions than the simple lowercase example node would suggest. This, in my view, simplifies the code and allows easier parsing of the various parts of the runtime.

Overkill if you only ever develop a single, simple node. But very powerful if developing multiple and complex nodes.

3 Likes
3

I think the development workflow / setup is very much a unique affair.

Example, I use VSCode, with its built-in console, and as I code, I can within VSCode, start my dev instance of Node-RED, test, make any changes I need, and restart Node-RED all within the same IDE.

I have shortcuts in VSCode to manage my Repo, and npm activity's at the same time, not to mention the IntelliSense.

I don’t find the HTML too annoying if I’m honest, I have a few boilerplate macros that I setup in VSCode, for the repetitive code blocks.

2 Likes
4

There are many ways to respond to this, I did it artistically - if you look at the modified flow and think of a hand, you will have my response.

I sometimes wonder what FlowFuse adds to Node-RED to make it "Team development" compatible, they go on to say: "Node-RED is an amazing productivity tool for an individual engineer. However, doing any type of collaborative development with colleagues is very difficult. FlowFuse allows for team development on the same Node-RED instances." Hang on, people are working together using the same Node-RED. Wait what? Do they all have VScode?

I think they don't all have VScode so perhaps making the tooling so simple, that product owners or stakeholders can actually participate in the development process would be a good thing - after all, connecting rectangles with lines isn't exactly rocket science.

But of course, only those people with VScode can call themselves "developers" and are allowed to modify Node-RED flows. God forbid if someone who don't use VScode should modify Node-RED.

Meanwhile products are delivered late and broken, needing constant updating because the developers simple didn't understand the problem domain. It's the fault of the product owners for not explaining everything to the developers, after all the developers use VScode, they know best!

Tell me, what are you doing to fix this for everyone? I know you fixed it for yourself, hell you've got VScode but the rest of us? We're all left out in the cold... using our miserable "oldschool" editors that don't take up 10GB of RAM and don't have spyware installed, oh pity us.

5

:rofl:

We make VScode available to everyone in the enterprise (>10k people) so that's not really an issue. It is used for many activities as we have lots of different code platforms. One of the benefits for me personally is the built-in, multi-kernel Jupyter notebook support. I don't have to run a Jupyter server which are real pains. And the notebook doesn't have to be Python based, Node.js is supported too as well as several other analytical languages. But, of course, I digress (again!).

I can't imagine that is any different for using EMACS? Devs will be devs after all (I'm an architect these days, not a dev :slight_smile: ). That should be handled by standard linting, testing and CI tooling.

I have tried to put in suggestions in the past. None of those have been taken up I'm afraid. I've also shared example nodes that illustrate some of the techniques for anyone who is interested.

Of course, I would hope that your question isn't suggesting that I don't do stuff for the Node-RED community :slight_smile:. Since I've spent hundreds, if not thousands of personal hours over the last decade helping people on the forum, raising issues, updating documentation, creating supporting documentation, creating example and support nodes and a selection of popular production nodes.

So anyone for whom I might have triggered an interest, they can always get in touch and I'll be happy to help them. And if more people decide that my approaches are helpful to them, perhaps it will become important enough to raise with the core devs.

Actually, currently taking up only 554MB of my 32GB of RAM. A bargain compared to my browser which is currently occupying over 3GB of RAM :exploding_head:

Actually, most of VScode is MIT licensed with only some under a freeware binary license. EMACS is, I believe GPL licensed. If so, it cannot easily be used in UK Govt/NHS and many other enterprises I'm afraid as it would be a restrictive rather than permissive license (noting that I'm not a license expert). Anyway, most of VScode is very open, as such, people tend to get rather irate if spyware is included.

Not at all, each to their own. Perhaps the next Node-RED survey could include a question on what tools people are using to develop with it. That would be quite interesting.

WellSomePeopleLikeSpinachJamesCagneyGIF

1 Like
6

For those that come after me, I continued on with the idea of Node-RED node development in Node-RED using Node-RED nodes and came up with the nodedev package which is maintained by this bootstrapping flow.

What the nodedev nodes provide is a representation of a node-package for deployment to npmjs or github. This flow is an example of its usage.

And why do this?

Because folks using Node-RED should not - IMHO - be forced to use a third-party editor to create their own nodes. You might agree or disagree with this idea, it does not much matter to me. If you think that this should not be possible nor allowed than don't use it, but don't tell me - I simply don't care. Node-RED can do this, I abuse Node-RED to do it, and if someone does not like it, then modify Node-RED, I don't much care.

Alternatively one could consider this a good idea and think about how to integrate it into Node-RED itself. Similarly as there was an attempt to allow subflow development within Node-RED - that seems to have gone nowhere. Again, I don't pretend to know how to do that, I am perfectly happy with this solution and have ported my node packages over (btw if you think I did that by hand, no - I built a tgz to nodedev nodes flow that did it for me - it downloads the package from npmjs and creates nodes for all files).

Either way, hope it helps and don't care if it doesn't!

2 Likes
7

Loving your creativity! And great examples, thanks for sharing. Even if people don't use this directly (and I'm sure some will), it has some really nice ideas that are worth understanding and borrowing with pride. :slight_smile:

1 Like