One of the side projects that has been ticking over in the background for quite a long time now is a linter tool for Node-RED flows.
Our friends at Hitachi have made a great start on it and I'm currently in the process of pulling it together to hopefully release alongside 2.0.
It will be an optional install (just like the Flow Debugger will be).
It will run either as a command-line tool on flow json files, or in the editor reporting back in realtime as you edit your flows.
One of the pieces missing at the moment is a really good collection of linting rules that can be used to check flows.
It has been designed to be pluggable, so that anyone can publish their own rules to npm and plug them into the tool. But we do want to make sure the core set is a solid starting point.
Now, I really want to stress the idea here is not to come up with a set of fixed rules that everyone must obey. Each rule has to be enabled before it is active. We will have a default configuration that applies a standard set, but users will be able to tune it to their own taste.
At the moment, we have the following rules:
avoid-loops - detects and warns if it detects a wiring loop
flow-size - allows you to specify a maximum number of nodes that should appear on any one flow.
http-in-response - warns if it detects any http in nodes that do not eventually reach an http response node. (And vice versa)
named-functions - warns if any function nodes have not had a name set
function-eslint - runs eslint against all of the function nodes
So my request to the wider NR community is for your ideas for any rules we could include in the core set.
The type of thing we're look for are:
rules that will help detect a bug in a flow
rules that will help ensure best practices are followed
rules that will help improve the overall quality of the flows.
Hi Nick,
I might not be the best reference for this, since I'm more busy developing instead of drawing flows all the time. But here is what pops up immediately in my mind:
Maximum number of chained nodes (directly chained, so not via a link-in/out pair), because I find very long chains of nodes very hard to read.
Perhaps too complex or not useful: if a sequence of N nodes occurs more than M times in a flow, then to advise for using a subflow (to avoid duplicate sequences)?
Warning if unused nodes and config nodes
Warning if a flows has no description (in the config screen of the flow tabsheet).
Warning when no Catch node is used, for companies that want to make sure that all errors are being handled??
Warning if output ports (on a node with multiple outputs) have no textual labels.
limiting the number of crossed connections per flow - not more than 3 crossed lines (link nodes should be used)
minimum space between nodes - e.g. nodes should not be overlapping, should always have a min space below to allow node status messages not overlapped by other noded
Multiple output nodes that have a "server" vs use of link nodes to a single output. For example, I much prefer a flow to have a single or pair of MQTT outputs at the top with just link-in nodes (or maybe with common data checks). I often have one that uses retained output and one that doesn't.
Then my main flows output via links to those nodes.
I will do something similar for InfluxDB outputs.
If it were possible, a check for nodes that overlap a group box but are not actually part of the group.
A check for nodes that have more than 1 wire from an output. Since that will make a slow copy of the msg object and you may want to avoid that.
A check for context/flow/global variables that have the same name under two different schemes (e.g. memory and file). That can cause hard to track-down bugs.
minimum space between nodes, avoid overlapping... There are times that I overlap nodes... For instance... I have Sensors that must have their live values published on several dashboard tabs 1. Operational Screens (specific Tab/Group), 2. Configuration Screens (separate Tab/Goup), 3. Calibration Screens (separate Tab/Group). Other than where these live values live.... the configuration is identical... so on my flows I will often overlap the 3 instances to save room... maybe not a good practice, but something I intend doing when projects have 8 or more sensors. So i guess that could be a [warn], but not an [error].
suggestions:
a switch node that doesn't go anywhere.... [warn]
excessively long node names that cause a node to grow wide in the horizontal direction [warn]
a node that is disabled in a flow and blocks the connections between the nodes behind and in front, disrupting information from 'flowing'. [warn]
So you do not need to activate a rule which will be not OK for you. But I think for a lot of use cases this will be a good thing.
Even if you have cases in which this is wanted, it can make sense to activate this rule and carry out a test and then check whether only the usual suspects are below the result.
I have seen some discussions in the past (and also once in my own flows) that a node was put on top of a wire. So it looks like the node is connected (both input and output), but the wire is just going beneath it. Very hard to find out why that node doesn't process any input messages... Moreover wires crossing a node in any other direction is also not really nice to look at, so perhaps detect wires crossing nodes?
@BartButenaers - I think the linter will be looking at the flow file - not the geometry on screen - but the rule there would be - flag any nodes with an unconnected input
Not ruling anything out at the moment, but it is true the flow file doesn't contain info about width/heights of nodes as they are calculated in the view. That does limit some of what can be done.
That said, it would be possible to have some rules that are 'editor-only' with access to the additional info needed.
Will there be an option to run a specific rule once?
For example, I would hate to have the linter always tell me that I have unconnected nodes when testing something, but occasionally running this would be nice.
(checking the box and then doing a deploy certainly will also work, but not as conveniently...)
Edit: I guess running it in the command line is the way to go then....
I had another (performance related) rule in my head, but I "think" this is only possible if some extra functionality would be added - in a far future - to the core. But I don't want to start that discussion here, to avoid messing up Nick's original question "ideas about rules". Do you want me to start another discussion, or should I wait until the first version of the Linter is published?
Given we don't know what you want to suggest, it's hard to say. If it's an idea for a rule, whether feasible today or not, then please just share it here.
all nodes should in a fixed raster (x/y coordinates)
There is an option to align with the grid. But I noticed with my flows that the position of many nodes no longer corresponds to the grid.
When a node has to deal with messages thet contain a large amount of data (e.g. video, audio, ...), cloning of messages has very bad impact on performance. So it is advised to use only 1 wire on the output of those nodes, since multiple wires cause cloning. And even if you forget to remove a disabled debug node on a second wire might cause high cpu/ram loads on a raspberry. Of course Node-RED has no idea for which nodes it has to perform this linter test. So I thought it might perhaps be useful if nodes can - when they are being registered - pass an array of linter hints to the core. Then I could add that e.g. in my multipart-stream node. On the other hand this might for my use case not be a 100% waterproof solution because my video messages would run e.g. through a Change node, and when you add 2 wires to the output of that Change node then my messages would be duplicated anyway (without the linter knowing it). So it is NOT a feature request, just a very basic idea ...
P.S. perhaps it is also useful to show a warning if not using the latest Node-RED version? Although that is not really a check of the flow itself... And there might be better places (e.g. in flow editor itself) to show such a reminder. So not sure whether it would be a good linter check...
Just to double check as I wasn’t aware of this: so the cloning is also happening in case of two outgoing wires where one wire is going to a disabled debug node ?
