I would be interested in hearing from developers of contributed nodes about how much effort they put into maintaining compatibility with older versions of Node-RED and whether there are methods they find helpful. The issue came up for me when a user could not install one of my nodes into a three-year old version of NR that was running embedded on a system where he does not have access to the command line. I have built a workaround, but don't yet know if it works. Without command line access, the user is not able to update NR or install an earlier version of my node. Updating NR from within the program is almost certainly out of bounds, if only for security reasons, but I wonder whether the editor could be given the ability to install specific versions of nodes, not only the current one. Any thoughts?
I use VScode with ESLINT set to a specific version of JavaScript to try and avoid making mistakes.
I did try to keep backward compatibility with Node.js v8 for as long as possible but eventually I got fed up with not being able to use modern capabilities. So once one of my dependencies in uibuilder moved to v10, I followed suit.
Similarly in the browser, once Microsoft announced the start of the end for IE and realising that browsers not supporting ES6 are now well under 1% worldwide, the effort of trying to stick within ES5 just became too much. Though I have said that if it causes someone a problem, I will run my editor html and front-ed library code through babel and build to ES5.
I guess that it would be possible to do but would take a fair bit of work.
I think that, as a work-around, I would just get a flow to install the old version and restart node-red then get rid of that part of the flow.
If somebody reports an issue with one of my nodes on an older version of Node-RED/NodeJs, then I first ask them why they don't upgrade.
If that is not possible (for a good reason), then I try to fix it when it is clear what is going wrong by looking at the stacktrace.
But installing older versions of Node-RED to investigate a single issue is something I rarely do lately. Simple reason is that I'm not a sotware company, and there are much more other things to do from which more users (and myself of course!) can benefit from...
In my case the issue was clearly caused by changes in the NR Module APIs and my enthusiasm for new features. So, I never even considered that changes in JS or node.js could cause problems
as well. 
If I understand your suggestion, this would involve getting an exec node to use npm to install the node. I considered that, but decided that fixing my code might be easier and more widely useful than trying to walk a single user through the process. It is also possible that his system is so locked down that he would have issues with permissions.
I confess 
that I continue to use BBEdit on my mac for almost everything. I have tried VScode and admire its features, so some day a problem will come along that forces me to make the switch. Meanwhile, I feel a bit like the woodworker who refuses to use power tools.
Neither am I... so I guess we hold ourselves to a higher standard. 
@drmibell :You can very easily install an old docker image, for a specific version of Node-RED/NodeJs. Then you are up and running in no time... However the first time that I had to that, I have spend quite some time (see here) to get my server side debugging up and running. But I quitted using Docker, because every thing I wanted to do worked differently in Docker. So do to a lack of time I quitted using Docker, although imho it would have been much better for my node developments...
Sounds very good. Unfortunately I quitted using VScode after a series of troubles to get it up and running. But this would also have been much better for my node developments.
Like I said before: I am not a software company that has lots of time and resources...
Nor me either 
All I'll say is that some messing with VScode over time has saved me masses of time and heartache.
Vscode is updated every month and keeps getting better and better. For example, you can connect to a remote (PI) and debug an application. You can run (and debug) npm scripts by just hovering over the script name in the package.json. git integration is fantastic. Hovering a dependency in package.json tells you latest version and provides a link to the package. Code completion and inference is too notch. Eslint is a lifesaver.
I could go on but I won't.
Also, if you are looking at any of your repos (or anyone elses) on GitHub, you can press . (dot) on your keyboard and your code opens in a web version of vscode right there in your browser. If you are logged in, you can even edit your code.
Lastly, it has improved lots over the last year or two (debugging improvements, editing experience, terminal experience, etc) Be worth giving it another go Bart.
Yeah I know...
Are you aware of a decent (recent) tutorial for starters?
@drmibell : sorry if we are going off-topic.
Microsoft's own tutorials are pretty good Bart.
I would just take it slow. It works out of the box with nothing to configure. But then as you get into it, try some of the Microsoft recommended extensions for nodejs/js/etc.
For anyone into Python and particularly into Jupyter notebooks, it is worth noting that VScode is getting very close to be vastly superior to all that messing around with Anaconda. Try installing the preview version of VScode and some of the extensions that let you run Jupyter with different kernels including a node.js one 
You can install the preview version along-side the live one.
And if you are into SQL, especially for MS SQL and Azure, try out Microsoft's also free Azure Data Studio which is also built around VScode but with a focus on Data.
And to get back to the original question of @drmibell : is it a bit "doable" to connect from VsCode to a running Docker container (with NodeJs version X and Node-RED version Y) to debug a custom node?
So long as you start node-red with -inspect
"Inspecting Docker Containers with Visual Studio Code" Inspecting Docker Containers with Visual Studio Code
Well I don't use Docker so I'm not certain. But maybe check out the remote editing extensions from Microsoft. There are 3. One for editing direct into WSL, annother for editing direct into a remote SSH session (that I do use regularly) and 1 for "remote" editing into a Docker container.
No worries. This is useful.
I wasn't really asking how to test but rather what to test -- or what I should feel responsible for testing.
Here is a not exactly hypothetical scenario:
- NR releases a feature update (semver minor version) that is backward compatible with the previous version.
- I update my node to use the new feature, test (using the new NR version) that it does not break existing flows, and release it as a minor update.
- Then I find that my revised node will not run under the previous version of NR.
Where did I go wrong? Or did I go wrong.? I never tested against the old version of NR, since it did not support the feature I was trying to use. Should I tell users to use only the current version of NR? That seems over-cautious. Should I always test against the previous version? If so, how far back in NR history should I go? I sometimes see contributed nodes that specify a minimum required version of NR, which makes me think I should take responsibility for providing this information. Or should I stop worrying and just fix things when they break?
I'm going to try to make things even more worse for you 
During the last months we were working on the Blockly node. Meanwhile the beta versions of Node-RED 2.0 were being published, which contained the Monaco editor offered by Steve. So we have installed at some moment the 2.0 beta to test both the ACE and Monaco editors. And it was not useless to test this, because we had some issues which we could solve with Steve's help.
Summarized: when I see features arriving in a beta (which I think "could" be relevant for one of my nodes), I will "try" to find some time to test that node on the beta version).
For one of my nodes I used a feature that was only available starting from Node-RED version X. When you used an older version of Node-RED, I showed a warning in the node's config screen and in the logs. However that polluted my code, and I don't know if that has much added value. Therefore I now put in my readme files that feature yyyy is only available starting from Node-RED version X. Of course I try to handle the error gracefully when an older version of NodeJs/Node-RED is being used... And imho this can be done only reliable by testing it on the older version of NodeJs/Node-RED...
But since I provide free software and support, there is no guarantee at all for any of this. If people still encounter a problem, then I try to fix it as soon as my private life allows this...
Don't worry too much about it, otherwise it isn't a hobby anymore 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
