Cross referencing this with another thread about what to do about "old / abandoned / unfit" nodes... could we perhaps eventually have the default view (both on flows. and in the editor) be only nodes that have been categorised ? IE once that have been at least minimally moderated / updated ?
1 Like
And perhaps some moderators might volunteer to manage moving things manually to an "old" or "archive" or "not working" or some other such category?
That would provide another layer and would spread the admin load a bit.
indeed.. "eventually" - meant after Nick had opened it up for a wider group of editors 
1 Like
Won't then a manual effort on the side of the package author speed this up: those packages that aren't categorised by their authors are good candidates for being unmaintained.
On the other hand, packages where an author has made an effort and added a set of categories is obviously still on the ball.
As Ive been going through the list, I have removed a handful of nodes already - some old, inactive dashboard forks and some for IBM services that no longer exist (ahem).
But yes this is all part of the tidy up effort. One step at a time.
Yes - I think we probably want both... but it needs to be outside of the actual node package (MHO) and in the library... so that whoever runs a library can set their rules - so a private / company library could just categorise approved nodes for example... (or indeed add their own categories)
I'm going off topic a bit but since there is a desire to allow the editor to choose the version to install. Would it be possible to add a section to a node page allowing the author to define the installable versions of his node.
By default (without the author's config) I suppose the choice of versions would be if the current version is 3.1.6 :
- 3.1.x (all patch versions)
- 3.0.latest
- 2.latest
- 1.latest
Not sure how that would work? Any published version should be installable - in line with the use of npm. The restrictions would be around the supported versions of node.js and Node-RED. It gets really complex very quickly.
What would be better is perhaps having a check for a CHANGELOG.
The goal is to allow the palette manager to install a version other than latest. The problem is that the catalog version array must not be huge.
It is under discussion 
Since it is trivial to have a string that will install any package from any location supported by npm and also to include any version spec, I would personally strongly recommend that you allow users to do this. Though possibly having a setting to allow restriction of source locations might be a nice feature for enterprise and school setups.
This is what I did when splitting uibuilder's front-end package library from core Node-RED. The input field simply allows any specification that npm allows. So, for example, I could install my own custom repo of VueJS (if I had one) with the latest v2 version using totallyinformation/vuejs@2 - the prefix is my GitHub user, then the repo name, then the version specifier.
This is easy to implement and provides maximum versatility to Node-RED managers. I would LOVE this as it would make switching between dev/test versions of packages and live absolutely trivial.
The category list looks well thought out and should cover many use cases effectively! Here are a few additional categories that might add value:
- Data Processing ā This could be useful for nodes that focus on ETL (Extract, Transform, Load) operations or other data manipulation tasks, which don't always fall under āDatabaseā or āAnalytics.ā
- Security ā As more workflows integrate sensitive information, a dedicated category for security-related nodes (like encryption, access control, etc.) could help users quickly locate these critical tools.
- Integration ā Since many workflows rely on combining various platforms and services, this category could encompass API connectors, authentication nodes, and other integration tools.
- Scheduling ā If there are nodes specifically for task scheduling, a dedicated category could be useful for workflows that rely on timed triggers or periodic tasks.
The initial list is solid, though, and itās great that youāre taking a flexible approach by allowing nodes in multiple categories and keeping it manageable.
1 Like
But wouldn't I expect to find that under your security category
These two are definitely worth adding to the list.
