# Nuclide Windows Support #321

Open
opened this Issue Jan 14, 2016 · 18 comments

None yet

### 19 participants

Contributor
 Nuclide is missing windows support, which causes many issues when users try stuff there.
This was referenced Jan 14, 2016
Closed

Closed

Closed

Closed

Closed

#### Could not uninstall nuclide-installer #295

added the windows label Jan 25, 2016
 I spent the past 20 minutes wondering why it wasn't working... D'oh!
This was referenced Feb 21, 2016
Closed

Closed

#### Nuclide file tree removes current file tree and shows nothing #375

 can we know when nuclide will support windows perfect?
commented Mar 11, 2016
 Some info about that on the site or the repo would be so appreciated! People(including me) spent their time trying to figure out what's wrong with it.
added a commit to DimitrK/nuclide that referenced this issue Mar 11, 2016
 DimitrK Added windows limited support notice on readme Included issue #321 which lists possible incompatibilities with windows version of atom 8513fcc
referenced this issue Mar 11, 2016
Closed

Member
 Basic functionality for remote projects appears to work on Windows. I'm using Windows 10 on the client side and Debian Linux on the server side. I can see the directory tree, edit remote files, and files are automatically reloaded if I edit them directly on the server. I haven't tested the more advanced IDE-like functionality such as Flow/Hack integration, but I imagine these would be fine as they execute on the remote server rather than the local machine. On the other hand, adding local project folders is totally broken. Nothing happens after clicking Add Project Folder and selecting a folder. The console has no errors, either. @mostafaeweda It seems like it'd be useful to have separate Github issues to track each Windows issue individually, rather than just having this one master issue for Windows support.
 any updates on windows release and where can I test it out now on windows?
commented Mar 20, 2016
 This would be awesome to have in Windows. I have been trying to use without any major hacks but no luck so far... :/
referenced this issue Jun 5, 2016
Closed

#### Unable to Uninstall nuclide-ocaml and all nuclide Packages on Win7x64 #530

 Perhaps a run-down of what does not work on Windows, and why? Maybe that'll assist us in knowing why this can't have proper Windows support.
Member
 Nuclide seems to run pretty well on Windows now. I've been using it for all my day-to-day work at Facebook (I'm not on the Nuclide team, I'm just an end user of Nuclide). I haven't encountered any major issues and for the most part it seems quite usable. Almost all of my work is done on a remote Linux server though, so I haven't really tested Nuclide with local projects. There may be issues with Hack/Flow for local projects as opposed to remote projects. Remote projects run typechecking/linting remotely so it's less likely to encounter issues with it. Sent from my phone. On Jun 16, 2016 4:37 PM, "Ryan Cole" notifications@github.com wrote: Perhaps a run-down of what does not work on Windows, and why? Maybe that'll assist us in knowing why this can't have proper Windows support. — You are receiving this because you commented. Reply to this email directly, view it on GitHub #321 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAFnHVRHTgz_cVldKK-JK7DLnlksxa5nks5qMd4fgaJpZM4HFVEP .
 @Daniel15 Ah, yea. I think the last time I tried out Nuclide (4-5 months ago) the Flow integration didn't work at all for local projects. Remote project makes more sense.
commented Jun 22, 2016 edited
 I have managed to get the flow type checker up and running on windows. I stumbled upon two issues when trying to get to work on Windows. First of all the way nuclide is trying to locate the binary even when specifying absolute path, is essentially running which flow or if the absolute path is filled out which c:\some\path\to\flow.exe. The problem here is that windows doesn't have the which command. I borrowed it from the git mingw binaries. I copied which.exe and msys-2.0.dll to c:\unix-utils and added c:\unix-utils to PATH. The second problem is that Windows is case-insensitive when using environment variables. And I have added the my unix-utils path to the already existing Path environment variable. But when nuclide access' the environment variable it does it by process.env.PATH which unfortunately was not where I added the path. So lastly I renamed the Path variables (both system-wide and local) to PATH, now I just restarted atom and it worked. Note: I have downloaded the pre-compiled windows binaries and extracted it to c:\flowtype and added that to PATH as well. Note: My Git for windows is faily new, and I found the unix-util binaries at C:\Program Files\Git\usr\bin on my x64 windows 10 machine.
Contributor
 Here are the steps I used to get Hack errors to show up in Nuclide on Windows using Vagrant/Virtualbox, if it's useful to anyone: Make sure your project has a .hhconfig file in the root Use Vagrant to launch an Ubuntu Xenial virtual machine. Install Vagrant Use vagrant init to create a Vagrantfile Set the box to be ubuntu/xenial64 in your Vagrantfile (config.vm.box = "ubuntu/xenial64") The Nuclide remote stuff needs port 9090 forwarded, so add config.vm.network "forwarded_port", guest: 9090, host: 9090 to your Vagrantfile For some reason the Xenial Vagrant box disables the /vagrant mount point by default. Re-enable it by adding config.vm.synced_folder ".", "/vagrant", disabled: false to your Vagrantfile vagrant up That should work, but mounting /vagrant will fail because for some reason the Xenial Vagrant box doesn't have the Virtualbox guest additions installed (See this bug), so install them with vagrant ssh and sudo apt-get update && sudo apt-get install virtualbox-guest-utils. Restart the vagrant machine (vagrant halt && vagrant up) and confirm that the shared folder now works by checking the contents of /vagrant. Get the typechecker working Install the latest version of HHVM from the instructions here. It doesn't actually have instructions for Xenial but the commands for all Ubuntu releases are the same and they do have Xenial packages hosted, so just copy and paste the commands for Wily. hh_client (well, actually hh_server) will refuse to run in /vagrant because it thinks its NFS and doesn't like that for some reason, but adding enable_on_nfs = true to /etc/hh.conf bypasses that error. cd /vagrant and run hh_client. Make sure you get some nice errors (add some errors to your code to confirm this). Connect the typechecker to Nuclide using Nuclide server Install the latest Node.js 6.x onto the Vagrant machine with the instructions here. Install the other things listed as Prerequests on this page, including the "watchman" thing which you have to compile yourself (although I'm not sure if the mounted files in /vagrant will even be watchable). Install the nuclide npm package, sudo npm install -g nuclide. In Atom/Nuclide, start a new remote project, or add a remote project folder with "Nuclide > Remote Projects > Connect to Remote Project...". Username is ubuntu, server is 127.0.0.1, port 2222, initial directory /vagrant I couldn't figure out the password for the "ubuntu" user, but the SSH key should be .vagrant\machines\default\virtualbox\private_key in your project root, so select "Authentication method: Private key" and use that. For some reason the nuclide-start-server command doesn't end up in your PATH after npm install -g nuclide, so change the Remote Server Command to /usr/lib/node_modules/nuclide/pkg/nuclide-server/nuclide-start-server. Click "Connect" and open a Hack file in the remote project folder. If all is well you should be able to get Hack errors showing up. If you have trouble, try watching the logs for the Nuclide server and the Hack typechecker in /tmp. Also check the Console in Atom (Ctrl+Shift+J) and the developer tools console in Atom (Alt+Ctrl+I). I noticed if you enable "Format on Save" option in the Nuclide settings, Atom spazzes out and gets stuck in a "file changed -> format file -> save file -> file changed -> .." loop, so I don't know...avoid that.
commented Aug 5, 2016
 Flow now supports Windows (since v0.30.0). Nuclide should work pretty well for JS projects, I guess.
Member
 Flow in Nuclide on Windows is constantly failing with write EPIPE [2016-08-14T23:23:05.147Z] [ERROR] nuclide - Flow failed: flow type-at-pos --json --path C:\Users\thoma\Documents\AwesomeProjectRN\index.android.js 13 22 --raw. Error: {"code":"EPIPE","errno":"EPIPE","syscall":"write"} C:\Users\thoma\.atom\packages\nuclide\pkg\nuclide-logging\lib\consoleAppender.js:39 [2016-08-14T23:23:06.170Z] [ERROR] nuclide - Unknown return code from Flow: undefined  Nuclide 0.161.0 Flow 0.30.0 Atom 1.9.8
Contributor
commented Sep 17, 2016
 @subtleGradient this is probably because flow is either not on your path, or it's found multiple times. Try running where.exe flow in a cmd/powershell (.exe is important for the latter) and manually copy one of the paths into nuclide settings. I'm working on a PR to fix this
 So, is this a good time for me to try to install nuclide on windows?
referenced this issue Sep 17, 2016
Closed

#### Which returns first result #712

added a commit that referenced this issue Sep 20, 2016
 zsol + Facebook Github Bot 5 Which returns first result Summary: This fixes a problem on windows where where.exe can return multiple lines if the command is found multiple times on the PATH. This is especially painful since the recommended npm install -g flow-bin creates two flow binaries on by default so the entire flow support is broken, as mentioned in #321. Also added tests. Closes #712 Reviewed By: nmote Differential Revision: D3892797 Pulled By: zsol fbshipit-source-id: 9de5a425f2f113525677e3dcae7ec3e1ec294bd3 5c96ef8
 what is the state of the project ? any updates?
 is full support of window in progress? any info?