@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 interface based 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.
nominate 
I’ve run virtualboxes a lot of times too, but could never get the same level of integration as I got with colinux. WSL pretty much is what colinux was so if 
- 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.