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

Get Help and Help Others
1

Let’s try something new. In light of ongoing conversations about developing Redwood on Windows (see this post and this post for examples), can we:

  • collaboratively outline TheBest™ Windows setup and best-practices in order to
  • create an “official” Redwood Doc for enhancing the experience of people developing Redwood on Windows?

This post is a Wiki. Anyone with Forum Trust Level 1 permissions is able to contribute.

How to Participate

Please edit, add, comment, and, most of all, improve the content below! Once it feels like we’ve reached a kind of consensus, we can migrate this Post to an official Redwood Doc.

—Edit Everything Below—

Developing Redwood on Windows

Expectations

[What is working. How developer experience should “feel”. Startup and installation times. Etc. Need to define the overall vision for Redwood experience on Windows, which, importantly, will set constraints as much as it sets benchmarks + expectations.]

Note: I suggest we focus this specifically on “Developing Redwood Projects on Windows” and not “Developing the Redwood Framework on Windows”. For the latter, I believe we have good-enough instructions within the Contributing docs. Will defer to Tobbe.

System Requirements

[Windows, Node, Yarn, etc]

Shell

[Which one(s)? Does Windows Terminal belong here?]

Storage: Physical (and maybe Remote)

[A bunch of things I (David) don’t understand: Local HDD, Local SSD, Local nVME, Remote NAS, Remote SAN, Over SSH (e.g. VSCode’s Remote SSH), Over CIFS/SMB (e.g. A “Windows share”), Over NFS… oh my]

2

^^ @Tobbe and @jeliasson What say you both?

3

While I am not targeted specifically, I participated in several discussion on this topic, probably in a pretty opinionated way (not anyone should be too impressed by my statements, because I am still a novice in the general Redwood context :grinning:)

Since I was an engineering manager with teams where everybody was trying to avoid Windows-based computers as the development machine, since the early 90th, I am certainly qualified to address many if not all @thedavid’s issues. My biggest problem is the prioritization of several areas I touched/initiated in my brief encounter with RedwoodJS:

  1. Anything Windows related ( I started here)
  2. Redwood IDE (started here)
  3. Redwood Authentication - I did not get the chance to say anything yet, as I wanted to first learn everything that exists so far.

@thedavid can you please suggest where should I start? Item 1. is the easiest for me, and item 2. requires a lot more learning before I could be productive, however, I see this as the most important addition to RedwoodJS (and I have a lot more ambitious plans than Aldo shared so far)

Item 3 is the reason I found Redwood - I wanted to create a very modern blogging platform for me, by integrating Ghost, Discourse and my own app that connects all parts - and that was meant to be a Redwood app. Now, I got “stuck” in RedwoodJS, because I obviously like it more than my own development plans

1 Like
4

A bunch of things I (David) don’t understand: Local HDD, Local SSD, Local nVME, Remote NAS, Remote SAN, Over SSH (e.g. VSCode’s Remote SSH ), Over CIFS/SMB (e.g. A “Windows share” ), Over NFS… oh my

I would not worry too much about such issues, as Erich Gamma & Co took care of all of this (VS Code Remote Development)

1 Like
5

I find this really hard to answer. I can say what works for me, but I can’t say if it’s the best way to do it, because I haven’t tried every other way.

What works for me is
Git for Windows
using git-bash
inside conemu
with node 15
and yarn 1.22.4

I haven’t yet tried Windows Terminal because it doesn’t support the transparency features I want. But as long as you use it to host git-bash I’m sure it would have rw feature parity with my git-bash+conemu setup.

A lot of Windows developers like using Window’s Subsystem for Linux (WSL), but I know the VSCode RW Extension doesn’t work there, so currently I can’t recommend that for Redwood project development.

1 Like
6

@Tobbe, I am pretty convinced that we should not focus on any particular platform-specific topic (like Window’s Subsystem for Linux (WSL)) but rather leave all such issues to VS Code (several hundred men/years spent to ensure the best platform-specific issues across the three major platforms. By doing that - we automatically solve the issue you raise above (VSCode RW Extension doesn’t work there)

7

can you please suggest where should I start? Item 1. is the easiest for me, and item 2. requires a lot more learning before I could be productive, however, I see this as the most important addition to RedwoodJS (and I have a lot more ambitious plans than Aldo shared so far)

Understanding that I’m putting on my “product manager” hat for this question, please know this is my perspective and not how you should do it. Open source is always a balance of passion + practicality. I’ll leave the determination up to you, of course.

The Core Team is increasingly focused on the v1 release and directing our efforts accordingly. Redwood Auth is in a great place and has many people in leadership already. It’s exceeded expectations for v1. The Redwood IDE, although being refactored, is also “good enough” feature-wise for v1 — the exception is a few outstanding bugs, which can’t be resolved until restructuring PR is complete. (Note: after v1 and restructuring of the Structure package, the sky’s the limit with the IDE.)

My Suggestion

As @Tobbe has mentioned, it’s possible and probably “good enough” to develop on Windows. But I think we could (and should) do a few things specifically for v1. If you were to create a Redwood Doc for “Developing on Windows” in the spirit of what I’m trying to do in this thread, it would be really helpful. The topics don’t need depth, but they do need to be explicit:

  • Expectations and Benchmarks when Developing with Windows
    • maybe include a vision or roadmap of things to improve
  • Recommended Setup (if any)
  • Setups that we know can work (e.g. Tobbe)

Missing Performance Metrics

Lastly, one thing that just came to me is the separate topic of starting to track the Frameworks “performance” metrics; things like build size, yarn rw dev start time, build time, etc. Take a look at this example of automatic “Stats from Current PR” from this PR in the Next.js project: Fix profiling plugin for next build by timneutkens · Pull Request #21989 · vercel/next.js · GitHub

Note: These Next stats are overkill for our current needs. But it could serve as a reference for us to make a list and tackle 3-5 stats to start with. The CI is run on GitHub Actions, which have both Linux and Windows runners.

8

I understand your position in making the proposal and its title (Windows Dev and Setup: Recommendations and Best Practices collaborative Wiki). I also like the title and your definition of the structure, so I will keep it at least until we together find something that looks better.

I do not sufficiently understand the [Collaborative Wiki] part as your current article appeared in the Discourse tool, topic Discussions & Questions. Can I interpret this as a suggestion to create a new topic with the slightly modified title Windows Development: Recommendations and Best Practices (so it can co-exist with your original post?

Do you think to use this approach: Using Posts as a Wiki? If so, I like collaborative editing only to a point, where the preferred approach is to write comments and in some sufficiently clear cases “in situ” editing as well.

9

Ah, well if the Forum feature is working correctly, you should be able to see and click the Edit button on my original post (admittedly not the best UI). Can you access this button to edit?

Screenshot

Screen Shot 2021-02-09 at 3.24.57 PM
Screen Shot 2021-02-09 at 3.24.57 PM1596×428 50.8 KB

10

No, David, there is no Edit button available for me. I will look into that and report back tomorrow

11

Well, that’s frustrating. Your account should have permission to edit the Wiki (you are at Trust Level 3). And I’ve followed this:

:thinking:

12

The thing is that the VS Code team themselves push pretty hard for their ability to develop across the WSL “fence”. See here for example Developing in the Windows Subsystem for Linux with Visual Studio Code And when people have that workflow set up for all their other dev they naturally want to keep using that for RW. I’ve had conversations with coworkers who just take for granted that anyone (I) who does web dev on Windows does so in WSL and don’t understand why we’re seeing different behaviour until I tell them I’m not using WSL

13

[…] until I tell them I’m not using WSL

@Tobbe Why would you dev on Windows without WSL? I mean, sure, some are afraid of the Linux terminal and all that but to me you really can’t be a efficient developer running strictly Windows. Well, you are a edge case I guess :sweat_smile:

Seriously tho. Should we continue to support “native Windows”? You are doing a amazing job identifying, fixing and supporting these users - but isn’t it time we “bump them up a notch”?

14

I <3 the Linux terminal. I use I sed, awk, tree, rsync, cat, less, curl etc almost daily, at least weekly. But I do it all using git-bash. http://gnuwin32.sourceforge.net/ is a great resource too :slight_smile:

As long as I’m on my current hardware I’ll stick with my current setup. When I get a new computer I’ll definitely try WSL2 (unless I get a MacBook…)

15

But I do it all using git-bash. http://gnuwin32.sourceforge.net/ is a great resource too

Isn’t that a bit like a bad terminal supporting wheels (stödhjul) :smiley:

It was such a long time since I used Cygwin/GIt-bash and all that. When WSL came around, I instantly fell in love. I guess it helped that I have done Linux since I was 15 years old.

When I get a new computer I’ll definitely try WSL2 (unless I get a MacBook…)

For now, I recommend sticking with WSL1. The extra complexity in WSL2 of not mapping ports to localhost is a little bit of pain and honestly not worth the extra FS performance.

If you still go the WSL2 route, here is a modified PowerShell script that does the heavy lifting for you when it comes to port forwarding. Hope it helps!

#
# Configuration
#

# You can change the addr to your ip config to listen to a specific address
$hostListeningAddress = '0.0.0.0';

#  All ports you want to forward separated (accepts string with dash as range, e.g. 8000-8010)
$hostPorts=@(8910, 8911);

# Firewall rule name
$hostWindowsFirewallRuleName = "WSL2 Port-Forwarding"

###########################################################################################################

# Get the IP address of WSL2 instance
$wslIPAddresses = bash.exe -c "ifconfig eth0 | grep 'inet '"
$wslIPAddressesRegMatch = $wslIPAddresses -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}';

# Check if we got an IP address
if ($wslIPAddressesRegMatch) {
  #  Get first match
  $wslIPAddress = $matches[0];

  # Ask user to confirm before we proceed
  Write-Host "We identified IP address $wslIPAddress on WSL2."
  Read-Host -Prompt "Press any key to continue or CTRL+C to quit"

} else {
  Write-Host "EXIT: IP-address of WSL2 could not be identified."
  exit;
}

# Implode all ports using comma as delimiter
$hostPortsImpoded = $hostPorts -join ","

# Remove Firewall Exception Rules
Invoke-Expression "Remove-NetFireWallRule -DisplayName '$hostWindowsFirewallRuleName' " | Out-Null

# Adding Firewall exception for inbound and outbound Rules
Invoke-Expression "New-NetFireWallRule -DisplayName '$hostWindowsFirewallRuleName' -Direction Outbound -LocalPort $hostPortsImpoded -Action Allow -Protocol TCP" | Out-Null
Invoke-Expression "New-NetFireWallRule -DisplayName '$hostWindowsFirewallRuleName' -Direction Inbound -LocalPort $hostPortsImpoded -Action Allow -Protocol TCP" | Out-Null

# Delete all current v4tov4 rules
$prevRoutePorts = Invoke-Expression "netsh interface portproxy show v4tov4" | Out-Null | Select-String '(\d{2,5}$)' -AllMatches | Foreach {$_.Matches} | Foreach{$_.Value};
foreach ($port in $prevRoutePorts) {
  $command = "netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$hostListeningAddress"
  Invoke-Expression $command
  Write-Host "Command: $command"
  Write-Host "Done"
}


# add port forward rules
function addPortForward($listenPort) {
  $command = "netsh interface portproxy add v4tov4 listenport=$listenPort connectport=$listenPort connectaddress=$wslIPAddress"
  Invoke-Expression $command
  Write-Host "Command: $command"
  Write-Host "Done"
}

# Loop thru all ports that are to be exposed
for( $i = 0; $i -lt $hostPorts.length; $i++ ){
  $port = $hostPorts[$i];

  # If port is int
  if ($port.GetType() -Eq [int]) {

    # Port-forward
    addPortForward($port);

  # If port is string with range
  } elseif ($port.GetType() -Eq [string]) {
    $delimiterIndex = $port.IndexOf('-');
    if ($delimiterIndex -ge 0) {

      # Define ports
      $hostPortRange = $port.Split("{-}");
      $hostPortFrom = [int]$hostPortRange[0];
      $hostPortTo = [int]$hostPortRange[$hostPortRange.length-1];

      for ($port = $hostPortFrom; $port -le $hostPortTo; $port++){

        # Port-forward
        addPortForward($port);
      }
    }
  }
}
16

Thanks! But the VS Code RW extension still doesn’t work, right?

17

Thanks! But the VS Code RW extension still doesn’t work, right?

Unfortunately no.

18

@thedavid @Tobbe @jeliasson Let me suggest a solution that ought to make everyone in this discussion happy:

It is not important to satisfy the few of us - this task is meant to show that Redwood supports all three platforms, and (even more) important that the Redwood platform behaves identically on all platforms. As @thedavid wrote

So, I will take the lead to create TheBest™ Windows setup, and the “official” Redwood Doc for enhancing the experience of people developing Redwood on Windows, which document will become the basis for our collaborative effort to make it the as good as we can muster.

Now a few words on the “wiki”. @thedavid suggested using this discourse (forum) software as the authoring tool for this effort. Based on my mini-research, Discourse has a long (6 years worth of) discussions on how to use their forum software as a “wiki”, but still not have the solution that properly addresses all wiki properties. I propose to use the GitHub wiki for this project, being under the impression that we have a very short timeframe to get this done.

@thedavid if you agree with the Github Wiki approach, please create the repo and let us know when it is ready.

1 Like
19

You still can’t edit the first post in this thread? Weird…
If so I’d just suggest you make a new post at the end of the thread, and then @thedavid, I, or someone else with Edit rights can update the first post when we’ve come to some kind of conclusion.

20

@thedavid - in order not to waste any time I created my own prototype, which will be moved to the RedwoodJS owned equivalent