Its an interesting idea. But, to be honest, I don't find that not developing in Node-RED itself to be the most annoying part of developing nodes. Not by a long way.
The complexity of the html file which makes development and linting hard. The fact that the html file and the node.js runtime file have to be in the same folder which causes issues with linting. The complexity of some of the Editor parts - especially typedInput. These are all, in my view, annoying complexities.
The inability to start moving to ESM from CommonJS and the requirement to have to restart Node-RED when you make changes to a node's runtime and reload the Editor when you've made changes to the html file. These are all annoyances too.
Or perhaps annoyances is a bit strong - complexities at least.
Also, npm publishing is not needed for developing, only for publishing. Node-RED can run nodes from local installs or from GitHub installs of course.
I think those updates are manual because there was an issue with the automation?
Old school! 
VScode, being node.js native, is a great fit for node development.
Personally, I develop using VScode with my dev instance of Node-RED running under PM2 with its watch function to automatically restart when changes are made.
I split the html file into the component parts and use a running gulp script to automatically update the html file on the fly.
For the runtime, I have a more structured layout of functions than the simple lowercase example node would suggest. This, in my view, simplifies the code and allows easier parsing of the various parts of the runtime.
Overkill if you only ever develop a single, simple node. But very powerful if developing multiple and complex nodes.
