Again, Windows Terminal is just that, a terminal. You need to specify what shell you mean as well. The shell is much more involved in how stuff works than the terminal.
Hi, @Tobbe
I will respectfully disagree, with a tiny bit of disappointment that you felt the need to say (quote below):
after you rightfully corrected me above.
So for the record, Windows Terminal is not “just a terminal”, but rather a brand new desktop application with built-in multiple shells, that are selectable via a tabbed interface (see below):
My point is that going forward, developing RedwooJS applications on windows can be done either using this Windows Terminal or VSCode, which give you access to all different shells without the risk of misconfiguration issues.
Remember, this document is intended to advise our customers how to develop on Windows, without having to use old methods. Naturally, we are only advising - so anyone who is not to be advised, will have access to the last section of this document that will list all known “tricks” from the past.
Hope that this resolves the issues related to the terminal versus shell confusion. Anyone with a different opinion, please pitch in.
@adriatic To my knowledge, the Windows Terminal don’t ship with built-in shells. You just configure which shells that are available (callable) - pretty much like VS Code.
{
"$schema": "https://aka.ms/terminal-profiles-schema",
"defaultProfile": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}",
"profiles":
{
"list":
[
{
"guid": "{61c54bbd-c2c6-5271-96e7-009a87ff44bf}",
"name": "Windows PowerShell",
"commandline": "powershell.exe",
"hidden": false
},
{
"guid": "{0caa0dad-35be-5f56-a8ff-afceeeaa6101}",
"name": "Command Prompt",
"commandline": "cmd.exe",
"hidden": false
},
{
"hidden": false,
"name": "Ubuntu-18.04",
"source": "Windows.Terminal.Wsl"
},
{
"hidden": false,
"name": "Azure Cloud Shell",
"source": "Windows.Terminal.Azure"
}
]
},
}
@jeliasson Hello, Johann
Thanks for your comment and allow me to explain: the WIndows Terminal (fetched from the Microsoft Store, does come preconfigured with CMD.exe, PowerPoint and Azure Shell. This may not be true if you get it from GitHub (I will verify and explain that). It would help, if you install it from the Microsoft Store and verify my claim 
You are also correct that this tool is configurable and it is worth mentioning that the configuration can be edited with the Visual Studio:
[…] does come preconfigured with CMD.exe, PowerPoint and Azure Shell. […] It would help, if you install it from the Microsoft Store and verify my claim
@adriatic Yes, the Windows Terminal comes preconfigured with CMD, PowerShell (sorry, no PowerPoint-support 
) and Azure Shell from the Microsoft Store. However, it is more important to focus on which shell being supported rather than the actual terminal being used. We might for example encourage the use of PowerShell over CMD, but not necessarily encourage to use Windows Terminal over just opening PowerShell. Don’t get me wrong, I love the Windows Terminal and use it time (w/ WSL) but that’s not where the supporting part of Redwood comes in imo.
[…] and it is worth mentioning that the configuration can be edited with the Visual Studio:
I am not sure why it would be worth mentioning that (as it’s just a (json) text file), or is there a specific way in Visual Studio that would open the settings for Windows Terminal that you are referring to?
One way of structuring the support scenarios for Windows could be a matrix, something like this;
| OS | Shell | Redwood Supported | VS Code Extension | Comments |
|---|---|---|---|---|
| Windows 10 | CMD | No | Likely | Please consider using PowerShell or Git Bash |
| Windows 10 | PowerShell | Yes | Yes | |
| Windows 10 | WSL | WiP | No | The VS Code extension will not work |
| Windows 10 | Git Bash | Yes | Yes | - |
Just a thought 
@Tobbe
To my memory, git bash is using a Linux emulated filesystem. If so, how well does it play with the VS Code extension? I would just assume that it has the same issues as WSL that way. Maybe not
That’s what I’ve been trying to say as well
I don’t know the technical implementation, but it is using the Windows filesystem. C:\ is mapped to /c/
So VS Code (and so also the extension) is using the files directly on the Windows filesystem. git bash is using the same files, but I’m not sure exactly where the “translation” from unix type filesystem calls to Windows equivalents are being made.
But I guess what matters at the end of the day here is that VS Code is running in Windows land, and the files all live in windows land, and so the VS Code extension works just fine
But I guess what matters at the end of the day here is that VS Code is running in Windows land, and the files all live in windows land, and so the VS Code extension works just fine
One would think so, but I guess VS Code is doing some magic behind the scenes when WSL is enabled that breaks this expected behavior. Like Git Bash, WSL mounts by default C:\ to /mnt/c/ (which can be changed to /c/ if one would like that). Anyway. Issue for another day.
Thanks for your comments, @jeliasson, and @Tobbe. Indeed Tobbe summarized my understanding of the problem @thedavid asked me to solve:
Let me make this even clearer: the document Windows Dev and Setup: Recommendations and Best Practices is intended for Redwood customers who either like or have to use the Windows platform. For them, it makes little sense to use kludges like git-bash, or any of the 5 Ways to Run Linux Software on Windows, just so they can use some of their favorite Linux development tools.
In my view (which I am expressing via this document) Redwood application development on the Windows platform is best supported by using VSCode for everything because Redwood’s future enhancements are all envisioned in the form of VSCode extensions, and our primary goal here is to ensure that.
If my understanding of @thedavid’s task for me is incorrect, I am sure he will let me know that. Until then, discussing my writings is a helpful, friendly exchange of opinions - exactly what this forum is created for.
What, in your opinion, are the benefits of using Cmd or even PowerShell instead of git-bash?
Let’s make sure to establish the right context for this specific exchange: Helping Windows “based” Redwood users to have the best User Experience developing Redwood apps. Those Redwood users likely do not even know what is git-bash, and may not like to have to learn it. The explanation that the git-bash is a part of git distribution does not change the fact that we are advising a class us users how to stay on Windows, without having to install parts that the company’s management may not allow.
@thedavid wrote (at the beginning of this discussion)
I suggest we focus this specifically on “Developing Redwood Projects on Windows” and not “Developing the Redwood Framework on Windows”
So, to answer your question, @Tobbe, I am not trying to “invent benefits” of CMD over git-bash as that would be idiotic to do. I am trying to describe the best possible context for Developing Redwood Projects on Windows, using my recollections of all possible constraints often imposed on the average software developer having to use Windows computer as the development tool.
Thanks for your post, giving me the opportunity to resolve this Linux versus Windows love/hate relationship which gradually crept into this discussion. No hard feelings I hope 
Happy to look things over and give my suggestions here when it’s ready.
I was a long time macOS user but as my 2014 MBP started to get slow, I moved over to a desktop windows machine. I develop a redwood project daily with Windows and WSL2. No major issues so far - been a great experience.
There are some quirks I have noticed:
- WSL layer can disconnect or hang (it usually needs a few mins to wake up again). If it’s bad, usually a reboot fixes it.
- When doing a yarn install, this can cause a lot of file changes, and can also cause the WSL layer to slow down or hang.
- The redwood extension does not work on WSL2.
1 Like
Thank you @viperfx - your recollections are very useful. I am trying to keep the “positive spin” throughout this doc, recommending the tools that work and do not diminish the UX. As you might know, the soon to come RewoodJS “IDE” will likely lead us into some great innovations - and that is completely dependent on VSCode.
The quirks you mentioned are cited often:
and in my opinion, these tools cannot be “recommended” by RedwoodJS
You and I can both only guess. No one knows where most Windows developers are coming from or what constraints they have on their machine/environment.
From the sound of other Windows developers here on the forum though, it seems as if most of them usually do their development in a WSL environment. And, again, just a guess here, but I think those would feel more at home switching over to git-bash than to Cmd.
I think most Windows users are going to have a better experience using git-bash than using Cmd. It’s also a more nix-like environment, and so is less work for RW Core team to keep compatibility with.
You’re going to have to try way harder than this to make me upset
Happy to “hear” that - I know many Swedes and they are all pretty non-temperamental
@adriatic and @thedavid, I fully understand and appreciate that you want to help Windows users to code using RedwoodJS. And I think it is worth doing that, because many people are using Windows (I get it). However I wanted to throw in an alternative path, as it has been working well for me, and perhaps other find it as a good option too. So, after you got your Ubuntu or Debian VM installed on Windows (should be pretty easy, these are the next steps I take, if anyone else would want to get up and running fast):
Install VScode & Install CURL and node:
sudo apt update
sudo apt-get install curl
curl -sL https://deb.nodesource.com/setup_14.x | sudo -E bash -
node -v
sudo apt-get install gcc g++ make
sudo apt-get update && sudo apt-get install yarn
yarn create redwood-app ./redwoodblog (or the name you want for your site/app)
yarn rw dev
check https://localhost:8911
Have fun with ReedwoodJS
1 Like
Hi, @smaurstad - thanks for the “recipe” to Install VScode & Install CURL and node, it will be added to the Windows Dev and Setup: Recommendations and Best Practices
Let me also address your comment
Here is another relevant quote: Apple reveals Windows 10 is four times more popular than the Mac.
Realizing that a vast majority of Windows computers are not used by software developers, there are still more developers using Windows than macOS. Think about all developers employed by large banks, government agencies, etc where the Windows environment is prescribed.
The most important fact in this discussion that in the context of JavaScript-based, software development, the developer is almost completely insulated from the native OS, so unless you are working on improvements to the V8 JavaScript engine, it is very unusual to use the native OS API 
The reason for @thedavid’s plea to pay more attention to Windows computers as the platform for RedwoodJS development tools is really none of the above - it comes from the fact that the Windows platform is a lot less well documented (better to say that the description of how to use JavaScript tools on Windows platform needs improvement).
It is finally worth mentioning that there are a few RedwoodJS core developers, who work on a very ambitious RedwoodJS framework integration with VSCode - and that is most safe to do on Windows, at least at the moment
I feel no pressure from you, quite to the contrary - I am sometimes pondering whether anyone cares ( 
actually not really).
I reached the state where the single biggest missing part is the description of how to use VSCode in some “advanced debugging” scenarios. For that, I need a well know application and have already concluded that the blog app described in the two tutorials is the best choice at the moment (I am planning to write a bit more “sexy” app as the model for next edition of the story in the wiki, where I would like to better present the storybook
Briefly stated: I am spending all my time going through Redwood Tutorials very carefully - and that takes more time than I expected (this means that I like the tutorials a lot)
1 Like
Stian (@smaurstad) The summary of my article windows-dev-and-setup-recommendations-and-best-practices is really:
node, yarn, and VSCode are all tools you need to develop RewoodJS applications on the Windows 10 platform,
I care to understand why is it that you chose the alternative set of tools
Is Linux or macOS your platform of choice, so that even when you develop on Windows, your want to have the “same” toolset, or do you have some more subtle reasons, that I care to understand a lot?
In particular, you are not mentioning VSCode, which works on all three platforms, a tool that is one of the best ever JavaScript tool that embeddes git, editor, terminal, and debugger.
HMR when using the windows filesystem in WSL2
I was having trouble with windows using WSL2 and hot module reloading, my code would not update upon changes. This was solved through making webpack poll by changing the dev command to:
yarn rw dev --forward="--watch --watch-poll=1000"
It would be good to add this to the config TOML file, if anyone knows the syntax, let me know
However, I suggest moving to using the Linux filesystem
Moving my files to ~/ then using explorer.exe . to access the filesystem from explorer (when in WSL) sped up yarn rw dev command at least 10X and mean’t I didn’t need to forward --watch-poll` in the command.
Further info:
https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/
https://docs.microsoft.com/en-us/windows/wsl/compare-versions
1 Like