I'd add to that, using any unsupported version - e.g. one that is too new as well.
And, throw in using an old version of Node-RED as well.
I already mentioned that one.
Please keep in mind this is doing static analysis of your flow JSON. The version of Node-RED you are using is not in scope here.
1 Like
Something for another process improvement then 
Julian,
I was assuming that multiple wires on a single output isn't really a problem in most cases, unless you really want to avoid cloning on only a few of the nodes in a flow. But that required that the linter was able to determine shomehow to determine which outputs needs this restriction. Because I personally don't need this restrictions on most of my nodes, only a few ones that do video processing.
But I'm totally aware that a linter might never have enough information to make this distinction! Just mentioning the use case...
Hi Bart, as the linter "just" checks the flows json file, I think that the easiest solution is to have it report any/all nodes with >1 wire on an output. That way you can review for yourself and if you are satisfied, turn off the rule again.
I would see it as probably something I would use periodically. As you say it is generally not an issue anyway.
1 Like
One more
- all nodes should be inside a group
That was already covered.
There was
If it were possible, a check for nodes that overlap a group box but are not actually part of the group.
But I request that are all nodes should be inside a group, it doesn't matter if they are somewhere alone or overlap a group box.
Hi there,
would it be possible to generalise the http-in-response rule to allow nodes to define a "required upstream" and "required downstream", presumably as a property in the .html file? This could be refined to include "forbidden upstream" etc. Specifying a list would say "requires A or B" or "forbids A and B".
So in RED.nodes.registerType('http in' ...
you would include the property
"required upstream": "http response"
and then the linter would do its magic
For my node-red-contrib-music supercollider node I would have
"required upstream": ["synth", "looper"]
and for the synth node I would have
"forbidden upstream": "soundfx"
It might be nice to have a more general type system on messages, but that's probably too complex.
Thanks,
Steven
2 Likes
There are issues, that can be at the flow level:
- All flow links are connected
And there are issues at the node level:
- Http in node protects parameters in the path with regexs
Would be great, if the nodes itself can contribute their own rules (and linters).
A few rules that would help in my style of development are:
Missing Otherwise rule in Switch node - warns if a switch node does not have an otherwise rule.
Debug node configuration - warns if a debug node is not configured to a user specified pattern (that is, for enabled/disabled, Output:complete message object/msg./JSONata, and To:debug window/system console/node status).
Missing connection - warns if a node has no input connection or has an output port with no connection.
The linter would be helpful if it runs from the command line and takes a static look at the flow file, but it would be much better if it ran live in the editor and could reflect changes in the flow as they are deployed and also allow the user to change the rules on the fly. Depending on how and where the linter output is shown on the editor, it would be nice to be able to clear warnings from specific nodes without having to disable the rule completely.
Yes, that's the plan. As I said at the start:
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.
Thanks. I saw that but wasn't sure whether "realtime" meant you could change, enable/disable, add/delete rules on the fly or clear warnings from individual nodes. Sounds like a good plan.
Still working through how you'd be able to mark a particular warning as "Okay in this case" for a given node without disabling the rule for the whole set of flows. Most likely approach is we'd add a comment to the node's info property (the description box in the editor) with some markup the linter can recognise to turn off a particular rule for that node.
I'm also working the the UI side of configuring the rules. At the moment it expects a static configuration in your settings file, but we'll have a way to edit the settings in the editor.
2 Likes
It sounds like the rule set is "universal." Why not associate it with the flow.json file? Then different rules could be applied to different projects, starting from a default set. Also, the rules file could contain instructions to ignore certain rules for certain nodes.
Not ruling that out, just not starting from that point.
A user will be able to have their own set of linting rules that are associated with the runtime via the settings file. I think it is far more common that once a user has got their preferred set of rules (that could just be the defaults we set), they want to stick with that for consistency across the projects they work on.
If they are using the Projects feature, then their linting rules could be included in the project repository - so if they have that connected to some CI system (like GitHub Actions) they could run the linter automatically whenever changes were pushed.
As I mentioned, I'm still thinking through how a rule could be disabled for a given node - a very common facility of code linters. Adding a comment to the node's info property (or the flow/subflow/group/whatever) is the best way to do that. And that would go beyond disabling rules - it would allow rules to be tweaked on a case by case basis.
How much of that customisation will be there with v1, I don't know. But we don't have to do everything on day 1.
2 Likes
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
