Ugh, that’s horrible! Your C drive is an SSD, right? How much free space do you have on it?
Do you have a feeling for if it’s a specific part of the process that takes a really long time? Are there any other processes on your computer that takes a lot of resources in the background? (Just look at mem and cpu usage in the task manager)
Hey Tobbe (@Tobbe ), its a SSD drive 128GB.
Has 99 Gb of free space so free space is likely not the issue.
That being said it’s certainly not a high end machine; its a rather cheap laptop which I have been using for a while so perhaps that’s a reason why its much slower.
For comparision purpose, the closest comparision would be perhaps a blitz.js app which takes 419 seconds (6.9 minutes) and creating just a normal react app with CRA takes 332 seconds (5.53 minutes).
In regards to consuming resources, when I am scaffolding a redwood app, my CPU actually hits 100% for a sustained period of time vs when using CRA I am generally around 81%.
When I am using neither, CPU usage is at 17% so I don’t think its something on the background, though I will perhaps wait for someone with a better hardware to post those stats 
Oh and yeah I am using VSCode powershell is just for bootstrapping app, and I tend to run CLI commands on powershell itself rather than the embedded terminal in VSCode, it tends to work faster on powershell itself.
Thanks for the update. So at least it’s not just RW that’s slow. That’s a relief for us, but doesn’t help you much…
I generally use a terminal outside of VS Code too. It’s what I’m used to and it works better for me. But you do know you can run PS inside the VS Code terminal, right?
Just so everyone is on the same page; when it comes to VS Code you can set which shell you’d like do use in settings.json (where WSL and git-cmd needs to be installed).
WSL
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\wsl.exe",
PowerShell
"terminal.integrated.shell.windows": "C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe",
cmd
"terminal.integrated.shell.windows": "C:\\Windows\\System32\\cmd.exe",
git-cmd
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\git-cmd.exe",
Or git bash, if that’s what you want to use
git bash
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
@adriatic Some feedback on your wiki pages
Leave all platform dependency issues to standard Javascript development tools (NodeJS, NPM/Yarn) and use Redwood CLI with a choice of several native “consoles” (CMD.EXE, cmder, Windows Terminal)
I think there might be some confusion here, so let’s first start by defining a couple of terms.
terminal = text input/output environment
shell = command line interpreter
So in general you’d use a terminal to interact with a shell. So a shell runs inside your terminal. Using the terminal you can instruct the shell to launch some other program, and so you’d interact with that program for awhile (like yarn, or prisma), until it exits back out to the shell again.
Some terminals let you interact with different shells, and some terminals only work with a specific shell.
Some examples of terminals:
Cmder
ConEmu
Windows Terminal
Some examples of shells:
Cmd
PowerShell
git-bash
To make it more confusing, Cmd is both a terminal (the “Command Prompt”) and a shell. git-bash is also both a terminal (git-bash.exe) and a shell (git\bin\bash.exe). And PowerShell is also both a terminal (that only runs one shell) and a shell.
So we can’t tell people to use (or not to use) a terminal that can host multiple shells without also specifying what shell we mean. So we can’t say “Cmder has problems with using single quotes”. We’d have to say “Cmder, hosting Cmd, has problems with single quotes”. Because if you’re running git-bash inside Cmder it works perfectly fine with single quotes.
In addition to NodeJS, NPM/Yarn, use VSCode as your principal tool. This way you do not need to depend on any text editor nor console, and you could use the identical tools set on all three platforms.
VS Code doesn’t call it a “console” (at least not with my locale). It calls it a terminal. And the VS Code terminal can host different shells. So again, if we want to recommend people to use the VS Code integrated terminal, we need to specify what shell to use as well.
Even more, your VSCode created application can be debugged on other supported platforms - a feature that no other approach will facilitate, not even WSL/WSL2.
What text editor or IDE I use does not influence how well my RW app can be debugged on other platforms. And the same goes for WSL. Using/not using WSL does not in any way change how any RW app can be debugged on other platforms.
RedwoodJS CLI a
command line interfacebased tool designed to generate (build) new Redwood applications from scratch.
I think the CLI is designed to work equally well with existing or old RW apps. It’s not just for creating new apps from scratch.
At the moment, there is a couple of issues, that speaks in favor of using yarn dependency management tool instead of npm
- it is a package manager that doubles down as a project manager, handling the smallest one-shot projects as well as enterprise sizes monorepos.
- it is free regardless of the set of features is supports
Meta:
Not sure whether the above issues qualify as advantages over npm, perhaps npm’s issue with the ‘create’ argument that require the syntax "npm create_newapp instead of npm create 'new-app is a better reason
I don’t think we need to even mention npm. IMHO it only adds to the confusion. And I don’t think npx create-redwood-app my-app is any better or worse than yarn create redwood-app my-app.
Thanks, Tobbe, for your fast response with great comments - the section
So we can’t tell people to use (or not to use) a terminal that can host multiple shells without also specifying what shell we mean. So we can’t say “Cmder has problems with using single quotes”. We’d have to say “Cmder, hosting Cmd, has problems with single quotes”. Because if you’re running git-bash inside Cmder it works perfectly fine with single quotes.
Incidentally, you fetched the text that I am typing in just know, so it is least vetted (by me, by re-reading them). That is not to say that I would catch all places you pointed out.
Since wiki content is not fully git-supported, I cannot ask you to create a PR 
- meaning that I will be responsible for manually merging your suggestions. This will not be too tough as I do not expect feedback from 25 people.
I kept both terms specifying that in this document both terms are used interchangeably. I know that many Unix users like console, and Windows user prefer terminal. Since we are trying to behave in a “platform independent” way, I wanted to keep them both. If more folks lean your way, it is a problem that is easy to fix
In order to avoid the confusion
I am recommending just two tools Windows Terminal and VSCode. This eliminates any user run console configuration problems, as both these tools come integrated.
That has yet to be written in mu document
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:
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
