In the spirit of things maybe nobody was asking for:
I really wanted two things: to build nodes as first-class Javascript/ES6 classes and to build them with TypeScript. Then I realized there was a lot of boilerplate involved in getting that all to work repeatedly for new nodes/packages, so I started building generators for it, one thing led to another, and now may I introduce you to:
There's a lot more content in the README at the link, and I do plan to improve both the template (adding tests) and the development experience (add watchers to rebuild as you edit the code), but I think it's already useful if this sounds like the way you'd like to be writing your node code.
Extending the idea that this might be a way of setting some basic "standards" to all contributed nodes so that they are fulfilling the basic requirements. I'm however not the one who can judge in details, never developed nodes but from a "management perspective" I would say it is a great idea
I was just thinking, not particulary of TypeScript, more in general terms that it could be a good (future) idea to. provide a kind of framework for node development in order to "align" and provide "basic features" in a more driven and harmonized way, maybe also help contributors make it faster and easier to develop nodes. As I wrote, just from "management view". I learned a similar lesson in my earlier professional life, managing a large team of developers responsible for interface development where I saw that we needed to harmonize the work better. We created a common, well call it templates or libraries, that was needed all the time any way; common features for logging, authorization, licensing, calendar, database, activeMQ etc etc. It proved to be very useful, preventiing people from re-inventing the wheel everytime. Maybe this is already in place for NR and nothing to worry about, as I wrote I have not implemented any nodes myself so it migh be the available guides are all that is needed. It was just a thought
It would be a severe backward step in my view anyway. It forces people to write stuff and in a way that isn't needed in a lot of cases, especially now that linting and type checking is so good when using things like VScode.
As long as that doesn't restrict innovation. For example, if everyone had to follow the design patterns of the early nodes, we wouldn't have the flexibility to use modern JavaScript to destructure the code into more logical functions or move to ES Modules without someone "centrally" saying that the standards had been updated.
In my view, one of the reasons Node-RED has been so successful is the low barrier to creating custom nodes. Yes, of course that also introduces issues around node quality but I've always been surprised how relatively few issues like that we get.
If, for example, it were to be mandated that "proper" nodes had to be written in TypeScript, that would be the end of my contributions since the whole reason I moved from PHP/Python/PERL to JavaScript/Node.js was to have a single language for both the front and back ends. I'm still learning how to master JavaScript and probably will be for the rest of my life - especially considering how fast it is developing - I don't have the time or energy to invest in learning Typescript. If anything, I would put it into Python which has many other uses.
Well, I think we already have some of that. Licensing is well understood. We have nodes for many db's. We have a standard logging method.
Sure, there might still be some clarification to do around best practice for authentication and authorisation and I think most people know my views on that. And there are certainly areas that deserve some better nodes - I'm thinking about data manipulation and analysis, something that Python is really good at because of the development that has been put into libraries like numpy, etc and that Node.js is relatively poor at. I'd love to be able to offer Node-RED to our data analysts at work but realistically, the tools that they need don't exist, not just in Node-RED but in Node.js itself.
This is interesting because I've been starting to think about how we can begin to encourage the move to ES Modules instead of CommonJS. However, I don't believe this is completely feasible until we move the baseline from Node.js v12 to v14 where we get things like top-level await which will make ESM/CJS crossover a bit easier. Still, that is close now.
The big issue right now is that you can use CommonJS modules in an ES Module fairly easily, but currently there is no feasible way to include ESM into CommonJS modules without significant recoding due to the need to use dynamic imports which return promises not the actual module.
For Node-RED which is CommonJS all the way down, I think this will be a significant challenge.
If anyone has worked out a reasonable design pattern for this that doesn't require you to recode everything to async processing, please do let me know because I could really do with it! I think that top-level await will certainly help because you will be able to use dynamic imports at the top level of your code which is where you normally put require or import statements.
(Sidenote: I did see that ES Modules are allowed when adding modules to a function node which is cool).
Oddly enough, having wanted to recently create some test nodes, I got round to doing something similar for native JavaScript based nodes TotallyInformation/node-red-experimental-nodes: An occasionally changing set of experiments for Node-RED (github.com) Nowhere near as well formed as your efforts to be sure since it is just a template for all of the files along with a Gulp pattern for creating and building the parts. I guess it wouldn't be too hard to extend to a full generator template though.
