In the spirit of things maybe nobody was asking for:
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.
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.
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).