Nuclide Windows Support #321

Open
mostafaeweda opened this Issue Jan 14, 2016 · 18 comments

Projects

None yet
@mostafaeweda
Contributor

Nuclide is missing windows support, which causes many issues when users try stuff there.

@ssorallen ssorallen added the windows label Jan 25, 2016
@SpencerSharkey

I spent the past 20 minutes wondering why it wasn't working... D'oh!

@SeananXiang

can we know when nuclide will support windows perfect?

@DimitrK
DimitrK 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.

@DimitrK DimitrK added a commit to DimitrK/nuclide that referenced this issue Mar 11, 2016
@DimitrK DimitrK Added windows limited support notice on readme
Included issue #321 which lists possible incompatibilities with windows version of atom
8513fcc
@Daniel15
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.

@whatsdis

any updates on windows release and where can I test it out now on windows?

@oizie
oizie 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... :/

@ryancole

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.

@Daniel15
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
.

@ryancole

@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.

@thetrompf
thetrompf 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.

@jesseschalken
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:

  1. Make sure your project has a .hhconfig file in the root
  2. Use Vagrant to launch an Ubuntu Xenial virtual machine.
    1. Install Vagrant
    2. Use vagrant init to create a Vagrantfile
    3. Set the box to be ubuntu/xenial64 in your Vagrantfile (config.vm.box = "ubuntu/xenial64")
    4. The Nuclide remote stuff needs port 9090 forwarded, so add config.vm.network "forwarded_port", guest: 9090, host: 9090 to your Vagrantfile
    5. 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
    6. vagrant up
    7. 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.
    8. Restart the vagrant machine (vagrant halt && vagrant up) and confirm that the shared folder now works by checking the contents of /vagrant.
  3. Get the typechecker working
    1. 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.
    2. 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.
    3. cd /vagrant and run hh_client. Make sure you get some nice errors (add some errors to your code to confirm this).
  4. Connect the typechecker to Nuclide using Nuclide server
    1. Install the latest Node.js 6.x onto the Vagrant machine with the instructions here.
    2. 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).
    3. Install the nuclide npm package, sudo npm install -g nuclide.
    4. In Atom/Nuclide, start a new remote project, or add a remote project folder with "Nuclide > Remote Projects > Connect to Remote Project...".
    5. Username is ubuntu, server is 127.0.0.1, port 2222, initial directory /vagrant
    6. 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.
    7. 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.
    8. 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.
    9. 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).
  5. 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.
@mesteche
mesteche commented Aug 5, 2016

Flow now supports Windows (since v0.30.0). Nuclide should work pretty well for JS projects, I guess.

@subtleGradient
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

@zsol
Contributor
zsol 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

@lednhatkhanh

So, is this a good time for me to try to install nuclide on windows?

@ghost Unknown added a commit that referenced this issue Sep 20, 2016
@zsol 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
@abdelouahabb

what is the state of the project ? any updates?

@myth2loki

is full support of window in progress? any info?

@slender9168

any updates ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment