This repository has been archived by the owner. It is now read-only.

# Nuclide Windows Support #321

Open
opened this issue Jan 14, 2016 · 27 comments
Open

# Nuclide Windows Support#321

opened this issue Jan 14, 2016 · 27 comments
Labels

### mostafaeweda commented Jan 14, 2016

 Nuclide is missing windows support, which causes many issues when users try stuff there.
This was referenced Jan 14, 2016
added the label Jan 25, 2016

### SpencerSharkey commented Feb 5, 2016

 I spent the past 20 minutes wondering why it wasn't working... D'oh!
mentioned this issue Feb 21, 2016
mentioned this issue Feb 28, 2016

### xyear commented Mar 8, 2016

 can we know when nuclide will support windows perfect?

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

### Daniel15 commented Mar 14, 2016

 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 commented Mar 19, 2016

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

### doubleppereira 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... :/
mentioned this issue Jun 5, 2016

### ryancole commented Jun 16, 2016

 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 commented Jun 17, 2016

 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 commented Jun 17, 2016

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

### mesteche commented Aug 5, 2016

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

### subtleGradient commented Aug 14, 2016

 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 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 commented Sep 17, 2016

 So, is this a good time for me to try to install nuclide on windows?
mentioned this issue Sep 17, 2016
ghost pushed a commit that referenced this issue Sep 20, 2016
 Which returns first result 
 5c96ef8 
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.

Closes #712

Reviewed By: nmote

Differential Revision: D3892797

Pulled By: zsol

fbshipit-source-id: 9de5a425f2f113525677e3dcae7ec3e1ec294bd3

### abdelouahabb commented Jan 10, 2017

 what is the state of the project ? any updates?

### myth2loki commented Feb 4, 2017

 is full support of window in progress? any info?

### yanisurbis commented Mar 3, 2017

 @subtleGradient hi, do you still work with flow, tried to install nuclide with flow - failed (code diagnostic doen't work) =(

### briandastous commented Mar 3, 2017 • edited

 Seems more relevant than ever because MacBooks lack adequate memory.

### fxbayuanggara commented Mar 15, 2017

 How is the progress for Windows support?

### DonChengCheng commented Apr 2, 2017

 what time ignite can full support windows

### agupta1989 commented Jun 17, 2017

 switch to ubuntu... better and reliable. 😎

### paulchill commented Jul 30, 2017

 I am using windows Atom with Nuclide installed - no option to add a remote project?

### alejoloe007jb commented Aug 11, 2017

 Cuando actualizaran una versión compatible al 100% con windows

### lednhatkhanh commented Jan 30, 2018

 Hello, is there news related to this?

### FibreFoX commented Apr 29, 2018

 So this bug is from beginning of 2016, are there any plans for supporting this? Is this bug even still valid? How is the progress on this one? What is missing?

### jakerjohnson21 commented Aug 25, 2018

 Update?