Windows Dev and Setup: Recommendations and Best Practices [Collaborative Wiki]

@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": "",
    "defaultProfile": "{c6eaf9f4-32a7-5fdc-b5cf-066e8a4b1e40}",
                "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 :yum: :smiley:

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 :wink:) 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 :slight_smile:

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 :slight_smile:


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 :slight_smile:

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. :slight_smile:

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 :heart_eyes:

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 :wink:

Happy to “hear” that - I know many Swedes and they are all pretty non-temperamental :wink:

@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 | 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 :smiley:

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

@adriatic how’s the wiki comming along? Is it ready for another review? No pressure, just curious :slight_smile:

I feel no pressure from you, quite to the contrary - I am sometimes pondering whether anyone cares ( :sweat_smile: 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:

1 Like