Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Dev Setup Doc #3685

Closed
2 tasks
thedavidprice opened this issue Nov 2, 2021 · 14 comments
Closed
2 tasks

Windows: Dev Setup Doc #3685

thedavidprice opened this issue Nov 2, 2021 · 14 comments

Comments

@thedavidprice
Copy link
Contributor

Windows devs try Redwood, using the "wrong" shell/terminal, and assume it's broken ('cause their local setup doesn't work). It's time for an official doc recommending the dev setup to use with Windows.

  • link to doc from Tutorial
  • bonus: during CRWA install, check for Windows env and warn accordingly

@simoncrypta

@thedavidprice thedavidprice created this issue from a note in Current-Release-Sprint (In progress (priority)) Nov 2, 2021
@thedavidprice thedavidprice moved this from In progress (priority) to v0.39 in Current-Release-Sprint Nov 2, 2021
@simoncrypta
Copy link
Collaborator

I think is a good opportunity to try all possible shell for windows and check the advantage of each of them. We can do a doc for something like Git Bash and another for WSL. But, I really think WSL2 is the best Windows setup, and it's the one Microsoft recommends. If we focus to make it work only with WSL, we don't need to do anything for Windows inside the framework since it a Linux environment. Any downside with WSL2 that I didn't know, @Tobbe or anyone who use Windows?

@simoncrypta
Copy link
Collaborator

simoncrypta commented Nov 3, 2021

https://learn.redwoodjs.com/docs/tutorial/prerequisites/

We recommend Windows users visit Nodejs.org for installation.

We could also change this sentence and refer to the Microsoft doc for NodeJS
https://docs.microsoft.com/en-us/windows/dev-environment/javascript/nodejs-overview

I have tested both approaches, and it works without problem for redwood projects.

Same for the warning in CLI when CRWA

@thedavidprice
Copy link
Contributor Author

@simoncrypta any/all of this would be amazing. And I agree that we just want to have one primary recommendation we make. (With the caveat others might be ok but Devs are on their own.) You don't need to do a deep-dive. Just simply confirm that a specific setup is working well.

Honestly, this is 80% of the way there:
https://community.redwoodjs.com/t/thebest-windows-setup/2439

And don't worry about making the writing perfect. We can help with that once the essential components are there. It just needs to be very practical, and step by step setup.

@Tobbe please do add your thoughts and help as available. I know you've learned a lot about this over time as well.

@realStandal
Copy link
Collaborator

Happy to see Windows getting some TLC, more than happy to change my workflow to ease the all-around strain.

I have a few questions with this setup, hopefully they're not just personal ignorance and can be useful in the docs to come:

  • Will the project need to be housed outside the Windows filesystem? (my gut and a few tests tells me "yes")
    • My terminology may be wrong here - basically, can we still access a project's files from Explorer?
    • The "Best Windows Setup" has something about this, but I didn't run into the exact issue listed there.
    • I tried to migrate an existing project, built using Powershell, to WSL and ran into issues running the rw command - even after deleting all node_modules and the project's yarn.lock and reinstalling them through WSL.
    • The same happened when creating a brand-new project yarn create ... within the directory I do most of my development from (a folder on my Desktop).
  • Can "legacy" projects, built using something other than WSL, be easily moved over?
    • Tying in with the above, is the best course of action to push the project to GitHub, then clone and reinitialize everything from WSL?
  • Are there special steps to access the development server?
    • I followed (roughly, albeit) the steps in the "Best windows" document, and am unable to access the server from my browser - I'm not seeing the "Welcome to Redwood" page found on new projects (both the web at 8910 and the API at 8911 are failing to connect).

More than happy to help with testing/whatever where needed, @simoncrypta :)

@simoncrypta
Copy link
Collaborator

I love these questions @realStandal ! I will try to answer the best I can.

Will the project need to be housed outside the Windows filesystem? (my gut and a few tests tells me "yes")

So you can use WSL with the Windows file system, but don't do it ! The performance is terrible, and you will eventually get error. The majority of problem with RedwoodJS on Windows is caused by the file system.

basically, can we still access a project's files from Explorer?

Yes you can ! You just need to mount it:
https://devblogs.microsoft.com/commandline/access-linux-filesystems-in-windows-and-wsl-2/

Can "legacy" projects, built using something other than WSL, be easily moved over?

Git clone is definitely the way to go.

Are there special steps to access the development server?

WSL2 made all the link between Linux and Windows, so via terminal you don't need to do anything special.
While using VS Code, you need to install and make sure you use Remote - WSL

I hope this will help you run Redwood on WSL, but if not you are more than welcome to DM me on Discord.

@Tobbe
Copy link
Member

Tobbe commented Nov 11, 2021

Honestly, if RW said it only supported WSL2 I would never even have tried it. My computer at the time just couldn't handle it. And even still, lots of people I talk to aren't thrilled about it.

We have two front-end developers who use Windows at work. Both use WSL.
One is running WSL on his 2020 Dell XPS laptop and he hates that it causes the fans to run at full speed even though he's not doing anything and that it's eating up all his memory for no good reason.

The other one mainly uses a m1 mbp at work, but at home he uses his kitted out Windows gaming rig. He says his Windows computer feels faster than his mac laptop, but of course it has 64 gb ram, top of the line amd cpu, super fast ssd etc. And the fans on the gfx card and on the cpu are always running no matter what, so any extra load from wsl isn't really noticeable.

I agree it would be much easier for us as RW framework maintainers if we could just tell everyone to use mac/linux/wsl. But I think it's much easier for Windows developers to get going with just git-bash and the included mintty terminal.

@simoncrypta
Copy link
Collaborator

simoncrypta commented Nov 12, 2021

Honestly, if RW said it only supported WSL2 I would never even have tried it. My computer at the time just couldn't handle it. And even still, lots of people I talk to aren't thrilled about it.

Thank you for that, @Tobbe, you confirm what I was worried about newcomer who jump in the NodeJS universe and also WSL2 have made a lot of performance patches, but it still really more CPU and memory intensive to run the same thing on WSL vs Git-bash or PowerShell.

What you feel about PowerShell vs Git-bash ?

@wiredmatt
Copy link

There's already nvm-windows, cygwin and git bash that you have already mentioned, also I see no issue with using powershell or cmd.

There are official postgreSQL binaries for windows as well..

Just idling, WSL2 consumes 2GB of RAM btw, not resource friendly, and definitely overkill for a javascript framework.

Just as I'm writing this I got a redwood app using powershell, had a hard time with getting the right node version, which seems that 16.13.0 is the only one working with redwood atm.

@Tobbe
Copy link
Member

Tobbe commented Nov 14, 2021

This issue comment was really interesting to read microsoft/WSL#873 (comment)

TL;DR: File operations will never be as fast on Windows as on Linux, but git-for-windows can do more optimizations than WSL can, so is a bit faster.

@Tobbe
Copy link
Member

Tobbe commented Nov 14, 2021

What you feel about PowerShell vs Git-bash ?

I'm not sure. I don't have enough experience with PS. I think it's probably mostly up to personal preference if you prefer PS or bash

@simoncrypta
Copy link
Collaborator

All right, so I think we can conclude that WSL2 is really not the best setup, especially for new people who want to jump and try Redwood for the first time. WSL2 take much more resource, is more complicate to install depend on which version of Windows you have, and you need to manage your Linux Subsystem. But, I think it can be a good option for Redwood Contributing, e2e with cypress work with WSLg, so we can recommend inside the contributing doc WSL2 for Windows user contributor.

Git-bash seem to be more appreciate and since it use bash, we probably had less problem than PowerShell.
I will try to use it for some days with a new Redwood project and write a nice doc with that. 😉

@thedavidprice
Copy link
Contributor Author

@simoncrypta Understood and sounds good! Thank you again for taking on this project.

@bosconian-dynamics
Copy link

bosconian-dynamics commented Nov 17, 2021

Just as I'm writing this I got a redwood app using powershell, had a hard time with getting the right node version, which seems that 16.13.0 is the only one working with redwood atm.

I have installed and been developing on Redwood using the CMD shell and various major releases of both the 14.x and 16.x Node branches without encountering any obstacles or issues. I use nvm-windows for engine selection, and do have mingw available in my environment, but I don't think that's a factor here. I wonder what the determining factors are

@thedavidprice thedavidprice moved this from v0.39 (locked) to In progress (priority) in Current-Release-Sprint Nov 18, 2021
@dac09 dac09 moved this from In progress (priority) to v0.40 in Current-Release-Sprint Dec 1, 2021
@dac09 dac09 moved this from v0.41 to v0.40 in Current-Release-Sprint Dec 13, 2021
@dac09 dac09 moved this from v0.40 to Ready to merge in Current-Release-Sprint Dec 13, 2021
@thedavidprice
Copy link
Contributor Author

Closing out. Moved remaining task to #3989

Current-Release-Sprint automation moved this from Ready to merge to Done Dec 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Status: Done
Development

No branches or pull requests

7 participants