For GitHub stuff, it is MUCH more comfortable doing edits in VSCode where you can also add a spell checker (try the "Code Spell Checker extension). 
As VSCode understands Git (though the GitLens extension adds some nice additional features even with its free version) it is simple to push changes back to GitHub.
I also recommend the "Markdown Al in One" extension for writing markdown more comfortably.
Yes I know. If anybody knows a step by step tutorial to setup vscode for a Node-RED node, that would be VERY welcome. Anyway I don't want to go offtopic here...
You mean running node-red from source? Or just for developing nodes?
I mean, just clone the repo then run npm run dev to start node-red from the terminal. If you so that command from a JS Debugger Terminal (inside VSCode), you get debugging.
Hey Steve, I have had time to look at vscode. Don't see the entire picture yet. Can any moderator split this please in a separate (interesting) discussion please? Would be nice to get some more details about it. Thanks!!
Hey @Steve-Mcl
I meant for developing and debugging custm nodes and dashboard D2. VSCode on a Windows portable and remote debugging on a Raspberry Pi. And perhaps things like hot deploy are perhaps possible?
Might be good to explain your setup(s) so there is no confusion.
For example, my main dev Env is Windows (not by choice 
). i also work with Linux via WSL and RPi (amongst others) but typically, this is done from the main windows box.
For example, you can connect to WSL and pretty much any linux box on your network using the Remote connection
FYI. You dont have to run Node-RED from source to debug a custom node. In the example where I connected to the PI above, that is just the .node-red dir (Node-RED is installed using NPM on that PI)
And yes, you can step debug remotely too.
And your ports get forwarded locally too
Ok thanks for sharing the videos!!!
Will look at them tonight, because my phone's screen is a bit too small...
I've used VSCode for all coding for some years now. Apart from the occasional foray into the Arduino IDE.
I don't do much remote editing myself as I develop on Windows (I've been using Windows as my desktop and before that OS/2 and DOS since the begging so all my muscle memory is tuned to it. ).
But for editing config files, I'll use it since it is much easier than struggling with nano and I never want to run a Linux desktop.
VSCode is also great for Python if you are into that and you can run Jupyter notebooks direct without needing a Jupyter server - indeed, I've managed to kick out anaconda from work because our Analysts and Data Scientists can now use Jupyter in VSCode. It even supports different Jupyter kernels so I can run a node.js notebook for example.
Hey @Steve-Mcl,
Sorry for the delay and thanks for the recordings!!
My development setup is (too) simple. Cloning my repos on a Raspberry Pi via git, and maintaining the code via nano. Then putting NodeJs in debug mode (via my node-red-contrib-inspector node which works very well) and remote debugging via Chrome. The Chrome debugger works well, but the file editing via nano is a bit too much Flintstones style 
And some time ago my test Raspberry has crashed, and to save time I use since then my productie Raspberry to debug also. So as a result if I forget to close my debugger, the lady of the house calls me that she can't open the garage door (because the code has reached a breakpoint) 
So perhaps it is better if I install a (test) Node-RED system on my Windows portable and I clone via git my custom nodes to my portable. And then manage the code and debug sessions via VSCode.
Would be nice if you could give me some tips: is such a setup a good choice? Do you manually restart Node-RED every time you have changed the code of a custom node, or is there some kind of hot deploy perhaps? Other tips to get started quickly?
Yes, this is good - if you want to keep a separate live and test/dev Node-RED setup. That's how I work. My test/dev instance is on my desktop, the live on my home server.
As I also use my alternate installer, I can also easily create new, clean installs of Node-RED even with different versions running in parallel. No impact on my live server.
Good grief - manual?! This IS the 21st C after all. 
No, my dev/test main instance runs under PM2 and I have its watch function watching files/folders that need to restart node-red.
Manual start and restart (when needed) as well as showing logs is done via npm scripts so I don't have to remember pm2 commands.
The location of files in Windows can be even more arcane than Linux these days. So personally, ALL my source code & dev stuff sits under a single root folder d:\src.
... back in a sec ... and back ...
So my node-red install folders go in there with their data as a sub-folder.
This makes it much easier to find stuff.
Nodes that I'm working on are cloned from GitHub and installed to the node-red instance using npm install d:\src\node-red-node-uibuilder or whatever. You have to remember to do an npm isntall within the node's root folder though otherwise things get a bit weird.
For VSCode edits, each root folder has its own workspace file (open the folder in VSCode then save the workspace - I save the workspace to the same folder but exclude the workspace file from git. I also use the Project Dashboard extension which gives me a quick access page with all of my local and remote workspaces to hand.
I really will get round to doing a write-up of VScode extensions - really I will - one day!
I think I've mentioned most previously. But here are the main ones:
For yourself, you might also want "Vue - Official". There are also vuetify extensions.
Of course, you should also set up certificate-based SSH logins and config so that VSCode remote can easily get to your remote devices as well.
VSCode has rather a lot of extensions but I try to install new ones and immediate disable then only enable them in each workspace as needed.
Oh, and I keep a Windows Terminal shortcut set up to kick off Node-RED under PM2, that is pinned to my taskbar for ease of access.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy
