Flow: Please provide Windows binaries

[StoneCypher]

There's a whole lot of Windows developers out there who would love to use this too, and who will contribute based on it.

[prabirshrestha]

+1

[m90]

+1

[Bartvds]

+1

[insin]

Has anyone tried building on Cygwin in the meantime? Looks like OCaml supports it:

https://ocaml.org/docs/install.html#Windows

Edit:

hack/heap/hh_shared.c:96:25: fatal error: sys/syscall.h: No such file or directory

If I delete the include and the syscall, I'm stumped because I'm on 32-bit Windows and integers overflow all over the place.

[StoneCypher]

Looks like OCPWin might be the way to go. Looking into it.

[henriknorberg]

+1

[stephen-gobin]

+1

[totty90]

+1

[lefessan]

There is actually no issue at all with compiling the OCaml part of "flow" on Windows. The following file (copied in build.ocp at the root of the project) will work ASAP on Windows using OcpWin (after ocp-build init and ocp-build build):

begin program "flow"
    cclib = [ "-lelf" ] (* comment this line under Windows *)
    requires = [ "unix" "str" ]
  files = [
(* comment these C files under Windows to compile only the OCaml part *)
    "src/embedded/flowlib_elf.c"
      "hack/heap/hh_shared.c"
      "hack/utils/realpath.c"
      "hack/inotify/inotify_stubs.c"
      "hack/utils/nproc.c"
      "hack/hhi/hhi_elf.c"
      "hack/utils/get_build_id.gen.c" (* This file should have been generated first, for example under Linux *)
      "hack/utils/get_build_id.c"

      "hack/avl/monoidAvl.ml" "hack/client/clientExceptions.ml"
      "hack/utils/path.ml" "hack/client/clientLogCommand.ml"
      "src/server/sysConfig.ml" "hack/utils/tmp.ml"
      "hack/socket/socket.ml" "hack/utils/ident.ml"
      "hack/utils/sys_utils.ml" "hack/utils/utils.ml"
      "hack/utils/lock.ml" "hack/client/clientUtils.ml"
      "hack/utils/pidLog.ml" "hack/client/clientStop.ml"
      "hack/utils/build_id.ml" "hack/utils/hh_json.ml"
      "hack/utils/relative_path.ml" "hack/utils/pos.ml"
      "hack/utils/errors.ml" "hack/server/serverMsg.ml"
      "hack/client/hackClientStop.ml" "hack/utils/shell.ml"
      "hack/client/clientStart.ml" "hack/stubs/eventLogger.ml"
      "hack/utils/tty.ml" "hack/client/clientBuild.ml"
      "hack/client/clientEnv.ml" "hack/client/clientProlog.ml"
      "hack/client/clientStatus.ml" "hack/client/clientCommand.ml"
      "hack/utils/config_file.ml" "hack/utils/wwwroot.ml"
      "hack/client/clientArgs.ml" "hack/deps/fileInfo.ml"
      "hack/deps/typing_graph.ml" "hack/deps/typing_deps.ml"
      "hack/heap/prefix.ml" "hack/heap/value.ml"
      "hack/heap/sharedMem.ml" "hack/naming/naming_special_names.ml"
      "hack/parsing/namespace_env.ml" "hack/parsing/ast.ml"
      "hack/naming/nast.ml" "hack/typing/typing_reason.ml"
      "hack/typing/typing_defs.ml" "hack/typing/typing_env.ml"
      "hack/typing/typing_hooks.ml" "hack/typing/typing_print.ml"
      "hack/server/argumentInfoService.ml"
      "hack/client/clientArgumentInfo.ml"
      "hack/globals/autocomplete.ml" "hack/globals/find_refs.ml"
      "hack/globals/ide.ml" "hack/naming/naming_ast_helpers.ml"
      "hack/naming/naming_hooks.ml" "hack/parsing/namespaces.ml"
      "hack/naming/naming.ml" "hack/naming/naming_heap.ml"
      "hack/naming/nastVisitor.ml" "hack/typing/typeVisitor.ml"
      "hack/typing/typing_exts.ml" "hack/typing/typing_hint.ml"
      "hack/typing/typing_utils.ml"
      "hack/typing/typing_instantiate.ml" "hack/typing/typing_tdef.ml"
      "hack/typing/nastCheck.ml" "hack/typing/nast_terminality.ml"
      "hack/typing/typing_expand.ml"
      "hack/typing/typing_unification_env.ml"
      "hack/typing/typing_unify.ml" "hack/typing/typing_subtype.ml"
      "hack/typing/typing_ops.ml" "hack/typing/typing_suggest.ml"
      "hack/typing/nastInitCheck.ml"
      "hack/typing/typingEqualityCheck.ml"
      "hack/typing/typing_alias.ml" "hack/typing/typing_async.ml"
      "hack/typing/typing_dynamic_yield.ml"
      "hack/typing/typing_enum.ml" "hack/typing/typing_extends.ml"
      "hack/typing/typing_generic.ml" "hack/typing/typing_lenv.ml"
      "hack/typing/typing_variance.ml" "hack/typing/typing.ml"
      "hack/server/autocompleteService.ml"
      "hack/client/clientAutocomplete.ml" "hack/server/serverError.ml"
      "hack/client/clientCheckStatus.ml" "hack/client/colorFile.ml"
      "hack/parsing/parser_heap.ml" "hack/typing/coverage_level.ml"
      "hack/client/clientColorFile.ml" "hack/globals/serverConfig.ml"
      "hack/heap/globalStorage.ml" "hack/parsing/lexer_hack.mll"
      "hack/parsing/parser_hack.ml" "hack/procs/bucket.ml"
      "hack/utils/fork.ml" "hack/utils/printSignal.ml"
      "hack/procs/worker.ml" "hack/procs/multiWorker.ml"
      "hack/server/find.ml" "hack/server/serverArgs.ml"
      "hack/server/serverEnv.ml" "hack/typing/typing_inherit.ml"
      "hack/typing/typing_decl.ml"
      "hack/typing/typing_decl_service.ml"
      "hack/typing/typing_check_service.ml"
      "hack/server/serverIdeUtils.ml"
      "hack/server/serverCoverageMetric.ml"
      "hack/client/clientCoverageMetric.ml"
      "hack/typing/typing_compare.ml" "hack/server/findRefsService.ml"
      "hack/server/serverFindRefs.ml" "hack/client/clientFindRefs.ml"
      "hack/server/methodJumps.ml" "hack/client/clientMethodJumps.ml"
      "hack/client/clientOutline.ml" "hack/server/serverRefactor.ml"
      "hack/client/clientRefactor.ml" "hack/parsing/parsing_hooks.ml"
      "hack/search/searchUtils.ml" "hack/search/fuzzySearchService.ml"
      "hack/utils/trie.ml" "hack/search/trieSearchService.ml"
      "hack/search/searchService.ml"
      "hack/search/hackSearchService.ml" "hack/client/clientSearch.ml"
      "hack/client/clientTypeAtPos.ml" "hack/server/fileOutline.ml"
      "hack/server/serverArgumentInfo.ml"
      "hack/server/serverColorFile.ml"
      "hack/server/serverFileOutline.ml"
      "hack/server/serverInferType.ml" "hack/server/serverSearch.ml"
      "hack/client/clientCheck.ml" "hack/inotify/inotify.ml"
      "hack/fsnotify_linux/fsnotify.ml" "hack/dfind/dfindEnv.ml"
      "hack/dfind/dfindMaybe.ml" "hack/dfind/dfindAddFile.ml"
      "hack/dfind/dfindServer.ml" "hack/dfind/dfindLib.ml"
      "hack/hhi/hhi.ml" "hack/parsing/parsing_service.ml"
      "hack/server/serverDfind.ml" "hack/server/serverEnvBuild.ml"
      "hack/server/serverHealth.ml" "hack/server/serverPeriodical.ml"
      "hack/server/serverFunctors.ml" "src/common/flowConfig.ml"
      "src/embedded/flowlib.ml" "src/common/files_js.ml"
      "src/commands/commandUtils.ml" "src/parser/spider_monkey_ast.ml"
      "src/common/reason_js.ml" "src/parser/parse_error.ml"
      "src/common/errors_js.ml" "src/common/modes_js.ml"
      "src/typing/constraint_js.ml" "src/typing/flow_js.ml"
      "src/typing/env_js.ml" "src/typing/type_inference_hooks_js.ml"
      "src/typing/autocomplete_js.ml"
      "src/server/autocompleteService_js.ml"
      "src/server/serverProt.ml" "src/commands/autocompleteCommand.ml"
      "src/commands/configCommands.ml" "src/dts/dts_ast.ml"
      "src/dts/lexer_dts.mll" "src/dts/parser_dts.ml"
      "src/dts/printer_dts.ml" "src/commands/convertCommand.ml"
      "src/commands/findModuleCommand.ml"
      "src/commands/getDefCommand.ml"
      "src/commands/getImportersCommand.ml"
      "src/commands/getImportsCommand.ml"
      "src/commands/portCommand.ml" "src/parser/lexer_flow.mll"
      "src/parser/parser_flow.ml" "src/parsing/parsing_service_js.ml"
      "src/typing/module_js.ml" "src/typing/type_inference_js.ml"
      "src/typing/comments_js.ml" "src/typing/getDef_js.ml"
      "src/typing/init_js.ml" "src/typing/sort_js.ml"
      "src/typing/types_js.ml" "src/server/server.ml"
      "src/commands/serverCommands.ml" "src/commands/singleCommand.ml"
      "src/commands/statusCommands.ml" "src/commands/stopCommand.ml"
      "src/commands/suggestCommand.ml"
      "src/commands/typeAtPosCommand.ml"
      "src/stubs/flowEventLogger.ml" "src/flow.ml"

  ]
end

[lefessan]

So, porting "flow" is only a matter of porting the 7 files in C...

[gabelevi]

There really are 3 main pieces of Flow and Hack that are platform specific

1. File system watching. This is inotify on Linux and fsevents on Darwin (MacOS)
2. Embedding libraries in the binary (libraries are gzip'd and stuck in the text section of the flow binary...then extracted at runtime). This uses libelf on Linux and mach-o/getsect.h on Darwin.
3. Shared memory stuff. I hear the mmap stuff we do wouldn't port well.

This is something we'd like to do sometime in the next year, but if someone wants to take a stab at it we'd be more than happy to take the PR :)

[totty90]

File system watching. This is inotify on Linux and fsevents on Darwin (MacOS)

Maybe we can postpone that for now. We can build manually for now. But at least should do the work (:

[lefessan]

From what I saw, there is no need to port part 2. (libelf/mach-o), as "flow" will also look up for "flowlib.tar.gz" in its environment (in the parent dir of its executable...). So, inotify and mmap... already quite some work !

[gabelevi]

Yeah, if you don't run the server as daemon, you don't need the file watching. And you can probably just stick the gzip'd libraries next to the binary and with a little hacking you don't need the embedded libraries stuff.

The shared memory part is a little trickier, but we've had success working around it for simple in-browser playground sorts of things. For example, the Hack tutorial runs the Hack typechecker in the browser without the shared memory stuff.

[cecilemuller]

+1

[pingec]

Flow looks like an improvement over TypesScript, would be great if it would run on Windows!
(+1)

[koistya]

+1

[lefessan]

@gabelevi: any hint on the trick to get rid of the shared memory stuff ?

[j201]

+1

It would be great to see this as a competitor to TypeScript, but Windows support is necessary for that.

[gabelevi]

@lefessan So the way Hack compiles to JS is that it replaces a few things with simplified versions. So normally Hack uses sharedMem.ml which calls to external C functions. However, when we compile it to JS, it instead uses a different sharedMem.ml which is greatly simplified and doesn't call into C.

[lefessan]

I used ocpwin to compile a very simplified version for Windows.
http://www.ocamlpro.com/pub/ocpwin/flow-builds/

Still a lot of work to do to get a fully working version !

How to use it :
unzip the file, there are 2 files flow32.exe and flow64.exe to use depending on your system.
You must set a variable FLOWLIB to point at the lib/ directory of flow:

On Cygwin (you must use it for now)

export FLOWLIB=c:/cygwin/home/user/flow-simple-windows/lib

The server has been removed, so it probably only works with:

flow64 single DIRECTORY

I hope it is enough to play with Flow on Windows, while waiting for an official Windows version...

[koistya]

@lefessan cool! Thanks, much appreciated.

[wchaowu]

@lefessan cool +1

[lefessan]

I uploaded a new version:
http://www.ocamlpro.com/pub/ocpwin/flow-builds/

Now, it should behave as the linux/macosx client, but without any multicore support. Works without Cygwin.

Feedback welcome !

[jquense]

+1. I was disappointed I couldn't try out flow. Is there word of an official stance or timeline? is win support a priority? it salads strikes me as odd when any new large web oss project is not cross platform. Why wasn't a tool choosen from the beginning (_cough_ node) that handled what's seems to be fairly simple platform deps?

also for a lot Windows devs something a cygwin dep is a complete non-standard.

looking forward to trying this out eventually! it would be helpful to know when that might be :P

[lefessan]

@jquense: portability is an issue, but writing a type-checker is a much harder issue (don't even think about doing it in Javascript...). So, they chose the best tool (OCaml) for the hardest problem, and they left porting as an easy problem... and indeed, it took us only two days to have a working Windows version (ok, no multicore and persistent state, the code is uggly, and it's not official, but it works !).

[pradeeproark]

@jquense linux or osx share a common root and it is pretty easy to port between them. Windows is always a different beast, same happened with git, node etc. It will take a while, of course you can jump in and try to submit patches to get windows upto speed.

[jquense]

@lefessan @pradeepcodes perhaps i came off as overly whiny, I didn't mean to pout. I mostly just wondering what the official stance is on win support. I realize the nix/osx are an easy port, and that windows if a different animal, i wasn't trying to say that it is easy to build something that meets the needs and is cross platform. My concern is more that when projects don't have cross-platform support as a priority from the beginning, the porting story is usually pretty bad for a long while (node is a good example). I am just wondering what the flow team's position on this is, and whether getting windows support first class is even something they care about. It helps me and my team when we know that flow will eventually be first class on windows, or its always going to be a "if ppl send the prs we'll merge them" sort of a support

[Davidhanson90]

Dog food comes to mind. Typescript compiler is written in Typescript. Not sure why OCaml was chosen but its good practice to build your compiler in the language your compiling, 😉 Anyways +1 for windows support.

[lefessan]

@Davidhanson90 : Scilab/Matlab compiler in Scilab, R compiler in R, is it really a good practice ? Writing a compiler is mostly manipulating huge trees (AST) in a recursive way, OCaml is a typed functional programming language with a feature called "pattern-matching" (check the manual, it's worth it !) that makes these kinds of manipulations much easier than in other languages... OCaml was also used for other languages, such as the first Rust compiler by Mozilla, Facebook Hack compiler, the Haxe compiler, etc...

[alt-]

@lefessan Thank you for the port!

Minor issue: I get an error when it tries to find the .flowconfig when run in a very specific path:

Fatal error: exception Sys_error("C:/Users/Owner/Downloads/flow-simple-windows-20141120/flow-simple-windows/./..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//..//

Changing the path slightly or doing a flow init makes it work fine.

[Davidhanson90]

@lefessan I'm not saying OCaml isn't a good language for it but I feel that it would be good to dogfood the language you're building. Maybe good practice is the wrong words. Anyways maybe the compiler will be written in flow when its done. 👍

Other languages with self hosting compilers.

◾Ada
◾BASIC
◾Burroughs Algol
◾C
◾C++ (compilers: Visual C++, clang, probably others)
◾C# and Visual Basic .NET via Microsoft Roslyn
◾CoffeeScript
◾Common Lisp
◾Crystal
◾Curry
◾Delphi
◾Eiffel
◾F#
◾FASM
◾Factor
◾Fancy
◾Free Pascal
◾Haskell
◾Java
◾Mercury
◾Modula-2
◾Nimrod
◾Oberon
◾OCaml
◾Pascal
◾Perl 6 (compilers: Rakudo Perl & Niecza Perl 6 are both self-hosting)
◾PL/I
◾Python
◾Rust
◾Scheme
◾Scala
◾Smalltalk
◾SML
◾TypeScript
◾XPL

[woopsie]

@lefessan just tried the 32 bit version. flow32 check runs fine. Starting the server with flow32 start doesn't return. (Win7)

I've just re-read you earlier comment wrt "the server has been removed". Did that still apply to the later version?

[lefessan]

@woopsie: indeed, I should have written it in the doc, that the server will not detach itself, it will keep running in the terminal (thus, not returning)... unless it is started in the background by another subcommand. I will try to find some time next week to understand how to detach the server.

[StoneCypher]

@woopsie @lefessan The windows equivalent of foo & is START "" foo

[Daniel15]

File system watching. This is inotify on Linux and fsevents on Darwin (MacOS)

@gabelevi For what it's worth, file system watching on Windows is pretty straightfoward via the .NET FileSystemWatcher class which can be used in C++ via C++/CLI.

[pradeeproark]

@Daniel15 would't that involve now instantiating the .NET runtime .. wouldn't http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx be more suitable.

[Daniel15]

@pradeepcodes Yeah, that should work too. I wasn't sure if there was a nice interface to it outside of .NET.

[nemoo]

+1

[Erid]

+1

[wajfaj]

what?

[lefessan]

I have uploaded a new version on http://www.ocamlpro.com/pub/ocpwin/flow-builds/. Everything works on my computer, so I am looking for feedback from other Windows users...

@gabelevi: would it make sense to put a link to my page from http://flowtype.org/docs/getting-started.html, for Windows users, with a warning that it is a "third party" contribution, .i.e external to Facebook ?

[lefessan]

@gabelevi : would it be possible to change the syntax of flow suggest FILE:line,pos-line,pos to avoid the use of ':' ? Since files on Windows can start with "C:\", the heuristics using ':' to find the region is broken. Maybe use '@' instead of ':' ?

[woopsie]

@lefessan looks like href for flow-simple-windows-20141127 is pointing to flow-simple-windows-20141120

[lefessan]

@woopsie : thanks ! It's fixed now.

[futurechan]

:+1:

[MetaMemoryT]

:+1:

Could the windows flow builds at http://www.ocamlpro.com/pub/ocpwin/flow-builds/ be set up with http://www.appveyor.com/ continuous integration?

[dougwilson]

Hm, yea, it would be neat to have "official" Windows support :)

[martindanielson]

Another developer here, mostly on Windows.

I swear that soon "nerds" and "hackers" will all be Windows users due to the amount of hacks we need to get all the libs working properly. Tide turning!

+1

[bitplanets]

Works with files in the same dir. But it will not look into sub dirs into my specific project. On an empty project work fine.

I think there is an error in a file that breaks the flow script silently because always shows "0 errors".

If I put the flowconfig in the current dir I have 3 errors. If I put a dir above I have 2 errors. In the exact same file! Fragile alarm here!

File

/* @flow */
define(function(require, exports, module){

    var _ = require('underscore');
    var utils = require('../utils');
    var fnFactory = utils.fnFactory;

    // Data:
    //  - player: Player game
    var ZI = function(data){
        _.extend(this, data);
        this.checkWaveStatus()

    }

    ZI.getPlayerZIScore = function(player){
        var XP             = player.XP;
        var totalGoldMined = player.totalGoldMined;
        var secondsPlayed  = player.stats.secondsPlayed;
        var planetsOwnedN  = player.stats.planetsOwnedN;
        var score = XP             * 3 +
                    totalGoldMined * 1 +
                    planetsOwnedN  * 10 +
                    secondsPlayed  * 1;
        return score;
    }

    ZI.canSendNextWave = function(player){
        var currentScore = ZI.getPlayerZIScore(player);
        var prevScore    = player.ZI.lastScore;
        var percentIncrease = (currentScore - prevScore) / prevScore * 100;
        if(percentIncrease > 30){
            return {
                yes: true
            }
        }else{
            return {
                retryInMs: (30 - percentIncrease) * 1000 * 10 * 1
            }
        }
    }

    _.extend(ZI.prototype, {
        checkWaveStatus: function(){
            var res = ZI.canSendNextWave(this.player);
            if(res.yes){
                this.sendNextWave();
            }
        },

        sendNextWave: function(){
            throw new Error('finish this')
            // this.API('sendNextWave');
        }
    })

    return ZI;
});

Output with flowconfig in the same folder:

E:\bp\Web\game07\src\client\ZI>flow64 check

E:/bp/Web/game07/src/client/ZI/ZI.js:2:1,6: identifier define
Unknown global name

E:/bp/Web/game07/src/client/ZI/ZI.js:4:13,33: underscore
Required module not found

E:/bp/Web/game07/src/client/ZI/ZI.js:5:17,35: utils.js
Required module not found

Found 3 errors

Now I move the flowconfig in the E:/bp/Web/game07/src/client folder:

E:/bp/Web/game07/src/client/ZI/ZI.js:2:1,6: identifier define
Unknown global name

E:/bp/Web/game07/src/client/ZI/ZI.js:4:13,33: underscore
Required module not found

Found 2 errors

Interesting.

[basarat]

+1

[reflog]

+1

[Cellule]

+1

[romseguy]

+1

[joshy]

+1

[kolo]

+1

[alexeibs]

+1

[juanka881]

I need this! +1

[juliankrispel]

+1

[bakesteve]

@lefessan any chance of an updated build? really need to grab this commit
if appveyor support is a possibility - that'd be ace!

[StoneCypher]

It would be great for an official build, because people like sindresorhus don't want to merge third party binaries (with good cause,) and are maintaining the binary packages that actually get invoked by the various toolchains out there.

An official build is meaningfully different than an identical third party build.

[mathieumg]

:+1: +1

[popopome]

+1

[vladimir-rovensky]

+1

[nadavov]

+1

[johnman]

+1

[StoneCypher]

So that's (counting +1 and :+1:) 32 so far.

Guess I'm gonna plus my own thing because I want to start a running tally by example.

+1 = 33.

[cskrov]

+1 (34)

[bakesteve]

+1 (35)
ps if any of the flow folks fancy giving an update here, or a preference on people registering their interest (watch this PR, uservoice, etc) that'd be great..
unfortunately no experience at all in ocaml, so cant really offer up any help on a PR with code (rather than +1s) , but be more than happy to jump in and help where we can (testing, appveyor CI setup, etc)

[boschni]

+1 because our teams are working on mixed environments and we cannot afford to use unsupported tools.

[mgamperl]

+1 (37)

[malonecj]

+1 (38)

[Draggha]

+1 (39)

[nekitozzz]

+1 (40)

[isiahmeadows]

Could this be fixed by using js_of_ocaml to port it to Node?

[macqm]

+1 (41)

[Flaise]

As though the developers don't already know how much interest there is in Windows support:
+1 (Meaning of life, the universe, and everything)

Just had to do it.

[StoneCypher]

@Flaise - amazingly, they don't.

[isiahmeadows]

Um... They realize. It's just there are specific things extremely difficult
to port IIRC, and it's not quite as high priority as fully addressing ES6
support, given projects like Cygwin.
On Mar 23, 2015 2:42 PM, "John Haugeland" [email protected] wrote:

@Flaise https://github.com/Flaise - amazingly, they don't.

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/6#issuecomment-85137536.

[xvik]

+1 (43)

[StoneCypher]

@impinball - a port is already present in this thread. All it needs is to be adopted.

[bakesteve]

Yep, we are using that already, and it works. But it is now significantly behind. Also having a non official build is meaningful (as mentioned above) ie for flow-bin on npm

[StoneCypher]

@spicyj You asked which thread. This one

[giltig]

+1 (44)

[Jaecen]

+1 (45)

[newtack]

+1 (46)

[AdriVanHoudt]

+1 (47)

[db]

+1 (48)

[seiyria]

+1

[n1ghtmare]

+1

[Cellule]

@lefessan would it be possible to share the work you've done to port flow back in November ? The version you made does work, but it is getting old now and it would be nice if others could contribute to the port.

[mohanr]

Is a WIndows binary available ? We have a big AngularJS application and developers are adding code too fast. My office machine is WIndows 7.

[StoneCypher]

@mohanr - not currently. That's why we're making a tally of how many people need it.

[Cellule]

@mohanr there was a port done back in November 2014.
You can find it here http://www.ocamlpro.com/pub/ocpwin/flow-builds/
However, in my case, this is not an option because it's lacking features that were implemented in the master branch a few weeks after that.

[ranuser99]

+1

[jdaley]

+1 (51)

[smonev]

+1 (52)

[Ciantic]

+1 (53)

[PixnBits]

+1 (54)

[webuniverseio]

@lefessan, I'm also interested if it is possible to share the work you've done to port flow back in November? If community will get the idea where to start we can try to update flow ourselves. Thank you. cc @Cellule

[Deathspike]

+1

[jozn]

+1

[Silverwolf90]

+1

[davidgilbertson]

+1 (58)

[Hoejsgaard]

+1

[m1sta]

Could the OCaml components be built with OcpWin and then bound into a node module perhaps?

[StoneCypher]

Yes, but until it's done by the official team, sindresorhus isn't going to bind it up into the main node module, so we'd still be locked out of the main path.

We just have to wait until the team thinks that having 92% of the programmers on Earth is important. And since they're Mac people, that'll probably be a while :cry:

[bakesteve]

Any ideas on if nuclide will support this? Or is that going to be based on a cross platform system (atom, and electron) but not reeaaly cross platform..

[StoneCypher]

You'd be a lot better off asking the Nuclide people that

[bakesteve]

Ha. Good point!

[m1sta]

@StoneCypher Maybe we could convince @lefessan to put together a more generic node module that allows use of OCaml and Node.js together (similar in concept to node-julia)? This is one of many times when I can see OCaml and Javascript as potential bedmates. Probably a discussion for elsewhere though really.

[lucynuri22]

On Apr 23, 2015 9:55 AM, "m1sta" [email protected] wrote:

Could the OCaml components be built with OcpWin and then bound into a
node module perhaps?

H>

Reply to this email directly or view it on GitHub.

[mysticatea]

+1

[SimonMeskens]

I managed to compile Flow on Windows. It doesn't seem to work quite yet, but should be close. Here's what I did:

• Install Cygwin with GCC and the OCaml packages and libelf (you might need some others, like m4 or maybe libbsd)
• make dummies for fsnotify.ml and fsnotify.mli
• run make

Compilation runs fine, the flow executable runs, but doesn't do many useful things. Running flow.exe repeatedly fails to run the server, running flow check gives a cryptic error: "Error initializing: Resource temporarily unavailable"

[alexander-entin]

+1

[delaneyj]

+1

[stanshillis]

+1

[LMLB]

+1

[m1sta]

Windows users who want to play with flow can try https://github.com/unknownexception/tryflow (aka http://tryflow.org/)

[StoneCypher]

@m1sta unfortunately we still cannot use it as part of our build systems.

[bakesteve]

Ditto
Though the js_of_ocaml approach could be promising I guess as we’re already running abunch of node in our pipeline

[astoilkov]

+72

This discussion is from November 2014. Is there any progress? Are there any plans and schedule when we will be able to run flow on Windows. Really excited about flow and waiting to get my hands on it.

[zpdDG4gta8XKpMCd]

+73

[motiz88]

While we all wait... :)
I have been happily running the latest Flow (0.11.0) for a few hours, with this Docker image I put together, on Windows.

The image has Flow preinstalled and in the PATH, so I just mount my source code at /app on a fresh container and start a Bash session inside it, where flow init, flow start, flow check etc work normally.

If you'd rather not keep a dedicated Bash window open, it should also be possible to, say, run the container in the background and docker exec <container_id> flow into it as needed.

Docker image specific discussion welcome at https://github.com/motiz88/flow-docker.

[zejafo]

+1 (75 I think)

[RinatMullayanov]

+1 (76th) very need.

[isiahmeadows]

Actually, we're at 66 of them (I counted them with help from Chrome's find feature). And I don't think any more "+1"s are going to get it fixed quicker, since it's only adding noise at this point. Subscribing to the bug is a much better way to show you want this feature, as it will reduce noise, which will help us know when an important update regarding this feature request happens.

So, could we please not reply with simple responses such as "+1" and "Me, too", and prefer more meaningful ones when appropriate?

Also, if you have a PR to even start this, please, by all means, submit it.

[PixnBits]

"Do not go gentle into that good night"
Building platform-specific binaries is so <timeperiod>.

Half of me agrees with you on the noise bit.
The other half points out that effort is put where interest is raised.

[StoneCypher]

@impinball - please finish reading the thread, where the PR has already been started. We will continue counting, because that actually does have an impact.

[JosephWoodward]

Heard about this on JavaScript Jabber podcast and was excited to try it. Gutted there's no Windows support so I can't use it :(

+1 from me for sure!

[burmisov]

Would like it too.

My another crazy idea was to make Flow watch a remote directory, then we could setup either a separate centralized linux-based "Flow server" to watch an SMB-mounted repository directory and somehow get results back from it, or run a local VM in a Vagrant style, do the checks there and feed them back to text editor or something like that?

[mcMickJuice]

+1

[aikeru]

I wonder how practical it would be to use one of the OCAML-to-JS compilers.
I don't know any OCAML devs, but I know plenty of JavaScript/node developers and some of them might be willing to try contributing to porting flow to node.
If someone with enough OCAML knowledge could make a compile of flow that would just leave unimplemented function calls or ... something ... for the C or platform-specific bits in a JavaScript compiled version of flow, I wonder how much effort it would take to implement those functions.

Does anyone see this as a viable idea?
I don't think I have time to learn OCAML and its ecosystem just for flow, but I might have some time to put into a node.js-based port of it. If someone gave step-by-step instructions I could use those to build to JS from this project on Linux and then work to port that to Windows.
...and +1 btw. Not having an official port on Windows totally sucks.

[aikeru]

Ok, even facebook is doing it http://flowtype.org/docs/coming-soon.html
Is there any work toward this "using js_of_ocaml" as listed on the coming soon page?
Is that part of fb's effort to make this cross-platform?

[doberkofler]

+1

[stuartallenmills]

+1

[StarpTech]

+1

[gabelevi]

Hi everyone! Sorry for the long radio silence! I'm happy to announce that @OCamlPro-Bozman and @OcamlPro-Henry will be working on building full Windows support for Flow! We're very excited to work with them and very excited to allow Windows users to use Flow!

We're just spinning this project up, so it will be a few months until this is completely ready. The development will happen through GitHub, so those who are interested can follow along :)

[aikeru]

@gabelevi please share as much as you can with the community! No doubt you have many willing potential testers and possibly even code contributors.

[webuniverseio]

Awesome news, thank you @gabelevi and OCamlPro team! :)

[gabelevi]

@aikeru The plan is to build Windows support as a sequence of pull requests against this repository and https://github.com/facebook/hhvm/tree/master/hphp/hack (which is the source of truth for Hack, upon which Flow is built). So you should be able to follow along to your hearts content! And I think @OCamlPro-Bozman and @OcamlPro-Henry will be very happy to have all the testers they can find when they're ready!

[StoneCypher]

WOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

[JosephWoodward]

Amazing news! Can't wait!

[kobezzza]

+1

[trikadin]

:+1:

[cyc0der]

+1

[barak007]

Can someone explain why this is not written in Javascript?
I want to flow in the browser......

[webuniverseio]

@barak007, there is a little bit of discussion earlier in this thread.

[lefessan]

@barak007, there is a very efficient OCaml to Javascript compiler (js_of_ocaml), so there is no reason why Flow would not be able to work in the browser. I imagine that such a version will appear at some point in the future.

About OCaml vs Javascript, all programming languages are just not equivalent. OCaml has features, such as static typing and deep pattern-matching that makes development much simpler and faster than in Javascript, and cheaper to maintain on the long term. For simple programs, it does not make a big difference, but for bigger programs, such as the Flow compiler, the difference is huge...

[webuniverseio]

@gabelevi, @OCamlPro-Bozman, @OCamlPro-Henry Looks like there were some work done already to adopt flow codebase for windows. I wonder if you guys have any update for those who are curious and impatient like me? :smile: Regardless of your answer thank you for hard work.

[motiz88]

Seeing as it's been 4 Flow versions and at least 20 comments since my last comment, I thought I might mention the Docker image again (source). It's a completely viable way of running Flow on Windows until we get proper binaries.

The actual update on that front is that I've just pushed v0.15.0 to Docker Hub (and automated the Dockerfile generation process somewhat using the GitHub API). I still need to run some steps manually for each new Flow version, so if the next one comes out and I haven't pushed it yet, feel free to open a corresponding issue on motiz88/flow-docker.

[webuniverseio]

Hi @motiz88, I'm new to docker and I wonder if there is a way to add flow to windows path via Docker, so that I can use flow for example for Atom IDE flow?

Thank you

[motiz88]

@szarouski, the folder sharing situation with Docker on Windows is such that atom-ide-flow would need to translate paths between your host OS and the environment running Flow. I can imagine contributing such a feature to atom-ide-flow`, but maybe it belongs in a separate helper app. Which, come to think of it, is quite doable - let me think it over a bit.
Feel free to e-mail me if you want to continue discussing anything outside of this thread.

[jonaskello]

+1

[SeriousM]

+1

[borabilgin]

+1

[henriknorberg]

+1

[SimonMeskens]

People, can we please stop spamming +1? The feature is already being worked on, you can track its progress through github. Right now, you're just sending out +1 mails to a large group of people that are waiting for completion.

[webuniverseio]

The issue is that it is not clear how to track its progress through github, there are no milestones. Public contributions graph from _OCamlPro-Bozman_ and _OCamlPro-Henry_ are not very descriptive too :[. I guess community is trying to show that support for flow on windows is important and would be very much appreciated... I guess we all need to get patient :).

[johnnyreilly]

What @szarouski said. :clap:

Is there somewhere we could be pointed to, in order to track progress more clearly?

[AlicanC]

We are living in a world where Windows usage share is 90%.

When the language you pick for your project has poor tooling for the 90% and you use APIs not available on the 90% and it takes you half a year to announce you _plan_ supporting the 90%, you end up getting these impatient plus ones. Software that can't work on 90% of the computers isn't free. Free as in beer, but not free as in speech.

---

Anyways, here are the commits of people who are working on this:

@OCamlPro-Henry (15 commits):
https://github.com/facebook/hhvm/commits?author=OCamlPro-Henry

@OCamlPro-Bozman (1 commit):
https://github.com/facebook/hhvm/commits?author=OCamlPro-Bozman

You should also be able to clone hhvm and git log --grep=windows.

Of course, you can't figure out how much actual work is left until this is over, but you can at least calm yourself knowing work is being done. (Or get sadder if you think not enough is being done :smile:)

[asivitz]

These are open source projects. Anyone is welcome to write the code to provide this windows support. Anyone is welcome to do some research and write a progress report. I'm waiting for this also, but I don't think the ones doing this work owe me anything.

[SimonMeskens]

They haven't just committed to HHVM, but also to Flow itself:
https://github.com/facebook/flow/commits?author=OCamlPro-Henry
https://github.com/facebook/flow/commits?author=OCamlPro-Bozman

On top of that, sometimes there's pull requests, which are then reviewed on Phabricator, like this one:
https://reviews.facebook.net/D45927

There's also these branches:
https://github.com/OCamlPro/flow
https://github.com/OCamlPro/hhvm

Most of the code written seems to be pushed to the branches first, so that's probably the best ones to follow.

[AlicanC]

@asivitz, I'm not trying to put anyone in debt. I would feel myself in debt, but anyone else is free to feel however they like.

Plus ones are a different issue though. If too much plus ones are disrupting the discussion, then plus oners are not to blame, but GitHub is, for not providing a better way to plus one.

For example, you can star issues on Google Code so you don't see any spam besides the occasional "Yo, this has 100000 stars and still not fixed, what the fuck?", of course immediately followed by much loved "Restrict-AddIssueComment-EditIssue" and its best friend "WontFix". (No one gives a better middle finger to the community than Chromium contributors.)

@SimonMeskens, those first two links contain the same commits on my links. We could keep an eye on OCamlPro forks though.

Doesn't Phabricator stuff end up here anyways? Is there any reason to follow that?

[cagdasbozman]

Hi,

A short report on our developments: we have started by porting Hack on Windows, since Flow shares a large part of the the code of Hack. You can follow all our commits on the Hack repository. We have now mostly finished our work on Hack and we are waiting now that all the submitted PRs to be merged (reviews in progress). We already started our work on Flow. The ultimate objective is to have all features of Flow working on Windows by mi-december. We will soon publish a branch on our repository for beta-testers, we will send a message in this thread as soon as it is available.

Regards,
The OCamlPro team.

[johnnyreilly]

Thanks @OCamlPro-Bozman! - BTW the Hack link is 404ing

[3mcd]

Very cool! Thank you!

[ColCh]

Which amount of "workhours" is for porting or ... any ETA? I should decide in a few days for myself - which main OS to use..

@motiz88 Nuclide is using very interesting idea for the feature named "remote development". In shorten, it installs a file watching service on server machine (OS X / Linux) and is using it's events on client machine via _SSH_ connection. I wonder if we could use same method for Flow (via _Vagrant_ + _Windows_). Just my crazy thoughts BTW :dancers:

[JoshZA]

:+1:

[jozn]

+1

[sahlouls]

+1

[bflora2]

+1
Yes, Windows... PLEASE

[jeff5665]

+1

[mshatikhin]

+1 Windows!

[sntulix]

+1

[bellicose100xp]

+1

[SC7639]

+1

[raybooysen]

Please can we close this issue for more comments for the moment. Constant flows of +1's don't really help other than cause a barrage of emails.,

[zpdDG4gta8XKpMCd]

[raybooysen]

No, I'd like real comments on updates to the work being done, not the
proliferation of +1.

On 1 December 2015 at 10:03, Aleksey Bykov [email protected] wrote:

[image: image]
https://cloud.githubusercontent.com/assets/937933/11497713/d220b48c-97e8-11e5-9538-e6b78972d06d.png

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/6#issuecomment-160920515.

[zpdDG4gta8XKpMCd]

http://flowtype.org/blog/

On Tue, Dec 1, 2015 at 5:11 AM, Ray Booysen [email protected]
wrote:

No, I'd like real comments on updates to the work being done, not the
proliferation of +1.

On 1 December 2015 at 10:03, Aleksey Bykov [email protected]
wrote:

[image: image]
<
https://cloud.githubusercontent.com/assets/937933/11497713/d220b48c-97e8-11e5-9538-e6b78972d06d.png

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/6#issuecomment-160920515.

—
Reply to this email directly or view it on GitHub
https://github.com/facebook/flow/issues/6#issuecomment-160924098.

Aleksey Bykov

[lefessan]

OCamlPro has been working on this subject for the last couple of months, there are about 4 pull-requests waiting for review on Github, and we are going to release a binary for beta-testers in the next days.

[trikadin]

Great news, guys, thanks a lot!

[Alphapage]

You have done a great job implementing flow as Vscode plugin.
It would be wonderful to be able to use the plugin on Windows too.
I hope it will be a reality very soon.
Thanks in advance.

[cagdasbozman]

Hi,

The work on porting Flow on Windows is going well. We are now looking
for testers, we have uploaded an alpha-quality binary of Flow for Windows so
that you can try it:

http://www.ocamlpro.com/pub/ocpwin/flow-builds/

All feedback is welcome !

Enjoy !

[AlicanC]

Great news.

[ColCh]

@OCamlPro-Bozman oh man this is amazing!

[Alphapage]

Seems to works great for now.
Which flow version does it implement ?
It would be great to be able to install from npm even if in alpha.
Thank you anyway.

[ghost]

This is based on a recent master, namely commit https://github.com/Facebook/flow/commit/ec9b5a65173ffa98d71359c584f995750df7cf27.

[StoneCypher]

@OCamlPro-Bozman ; @OCamlPro-Henry : thank you very much :grinning:

[aikeru]

@OCamlPro-Bozman @OCamlPro-Henry So awesome! Thank you so much! Where/how should we go about opening any issues, should we find them? :)
Should we start opening "windows" related issues on the flow repository? Anywhere else?

[maximus8891]

Thanks for the binaries!
For windows do you have to use backslashes \ in the [ignore] section in .flowconfig? Regular slashes don't seem to match correctly.

[cagdasbozman]

I will fix this soon, for now you can just use a regexp to handle backslashes \, for example:

[ignore]
.*[/\\]tmp*

[cagdasbozman]

Hi,

We are pleased to announce a new binary release of Flow (0.19.1) on Windows:

 http://www.ocamlpro.com/pub/ocpwin/flow-builds/

All features are now implemented and ready for testing, we are looking
forward to your feedback ! Enjoy !

The OCamlPro Team.

[m1sta]

Hooray! Thank you!

[asivitz]

Thanks so much for your work on this! Bug reporting is disabled in the OCamlPro/flow repo so I'll post an issue here:
I'm getting a seg fault when checking many files (for example, a node_modules directory). But the test file checks fine, and my project will also check fine if not including node_modules (except for all the type checking errors of course).

[asivitz]

Has anyone had success building from master recently? The current master will not build. Looks like there has been some refactoring that broke windows support.

[ghost]

I did not try to build master recently, but even if it would build, some PRs are not yet merged and as today the resulting binaries won't be fully functional. There is an important modification on the concurency code, it have impact on the linux version and it requires carefull testing. Hence, the delay. But testing is doing great and remaining merges might happen in a near future.

[TimMensch]

I've tried the current Windows build, and instead of being super fast, it takes ~19-35 seconds to check a very small set of files. I don't see Issues enabled on the OCamlPro page, or I'd file one there. Would love to use this, but it needs to be faster; any word on when the next update is likely?

[aikeru]

@OCamlPro-Bozman @OCamlPro-Henry hey guys ... the link with the builds appears to be down, it's reporting page not found ... is there a new link? Am I missing something obvious?

[cagdasbozman]

@aikeru Sorry for the inconvenience, we did some maintenance on our server yesterday, it should be fixed now.

[cgbystrom]

Latest version (0.19.1) crashes when running in server mode.
flow check works fine though.

1. Use Flux chat example from the Flow repo
2. Run flow server and modify a file
3. Crash :(

[2016-02-28 16:05:15] Initializing Server (This might take some time)
[2016-02-28 16:05:15] executable=c:\flow-master\examples\flux-chat\flow.exe
[2016-02-28 16:05:15] version=0.19.1
[2016-02-28 16:05:15] Parsing
[2016-02-28 16:05:15] Running local inference
[2016-02-28 16:05:15] Calculating dependencies
[2016-02-28 16:05:15] Merging
[2016-02-28 16:05:16] Server is READY
[2016-02-28 16:05:16] Took 0.641000 seconds to initialize.
Fatal error: exception Unix.Unix_error(31, "read", "")
Raised by primitive operation at file "unix.ml", line 293, characters 7-33
Called from file "hack\utils\timeout.ml", line 180, characters 19-75
Called from file "hack\utils\timeout.ml", line 188, characters 16-36
Called from file "hack\utils\timeout.ml", line 218, characters 38-59
Called from file "hack\utils\timeout.ml", line 311, characters 17-40
Called from file "hack\dfind\dfindLib.ml", line 30, characters 12-43
Called from file "src\server\serverFunctors.ml", line 192, characters 22-66
Called from file "src\flow.ml", line 86, characters 2-19

Running on Windows 8.1.

Update:
Also get weird errors about files missing at startup when Flow is scanning through node_modules.
The paths outputted by Flow are all over 255 chars, which on Windows is a big no-no.

Installing npm v3 where all packages inside node_modules are flattened actually solved the problem about the paths. Possibly related to crash mentioned above? I don't know.

[StoneCypher]

@OCamlPro-Bozman @OCamlPro-Henry - it may be smart to set up a dummy Github project, so that people have a place to report issues?

[Cellule]

@StoneCypher The project exists https://github.com/OCamlPro/flow , but the issues are disabled.

[StoneCypher]

well, that'd be a place to start :wink:

[samwgoldman]

Please file issues in this repo. Windows support isn't a separate project. We will make sure the issues are seen by the right people. Of course, please include that the issue is in the Windows prerelease if that's the case.

[StoneCypher]

Oh, okay. :+1:

[fenduru]

:+1:

[SnareHanger]

:+1:

[joowh85]

+1

[joshaber]

The Windows binary is 5 versions behind. Is it still being worked on?

[Phoenixmatrix]

I was curious about the same thing. Looks like Linux userland for Windows will come out first ;)

This is somewhat of an awkward problem, since Flow is honestly better than TypeScript, but in an open source project, I can't lock myself out of such a huge chunk of potential contributors. I'd love to help, but the parts required for the port are squarely in my software engineering blind spot :(

edit: reread myself and that sounds pretty entitled, sorry, I didn't mean it that way! I'm just a curious fan, nothing more.

[buzinas]

since Flow is honestly better than TypeScript

@Phoenixmatrix Based on what?

[trinitroglycerin]

@buzinas In my opinion it's mainly based on the fact that TypeScript doesn't interop very well with the existing Node base without specific files (as it assumes a module simply doesn't exist if there aren't typings for it, and there are _plenty_ of libs without typings). Yeah I could write typings for them but when it's for a majority of libraries I use...

Not mention there are several simple idioms in JavaScript that just don't work in TypeScript. The following won't compile in TypeScript for example:

class ClassA {
  constructor() {
    this.myField = 'foo'
  }
}

You need to explicitly define the myField: string field in order for the above code to compile.

Flow has the right idea and gracefully accepts that some things will be untyped and it should just accept them as any.

[mathieumg]

@danpantry Had you seen about Salsa?

[trinitroglycerin]

@mathieumg No, that's pretty interesting, though I can't start using it yet as I'm not entirely sure I have the ability to fiddle with the registry on this laptop.

[mathieumg]

If I got that correctly, you only need a switch since 1.8 shipped: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#including-js-files-with---allowjs I haven't used TS in a while though, so I'm not 100% sure.

[trinitroglycerin]

we already use allowJs. It results in errors complaining that files will be overwritten. Additionally, the Visual Studio 2015 version I have still has broken syntax for nearly all ES6 features for .js files. :(

[buzinas]

@danpantry VSCode is much better for JS/TS development.

[trinitroglycerin]

@buzinas Therein lies the problem. It doesn't come with baked-in TFS support (which we use, sadly, though is available through an extension), isn't approved by the business and doesn't work very well with .sln either (our front end project is in the same solution file as our back end project).

Hands are pretty tied, so I stick to using SublimeText (which I am used to and actually supports the correct syntax highlighting) with git-tfs and manually modifying the .csproj file

Last time I used VScode it was breaking on import/export statements

[buzinas]

@danpantry I see.

We had the same problem here, as we were using TFS and the same SLN for frontend and backend development. But fortunately, I was able to convince the managers to separate the projects, and now we use VSCode + Git, and it's being a delight experience.

I'll quit the conversation now, because it's completely off topic to the issue, and probably there are tons of people receiving notifications from this. Have a good one :)

[StoneCypher]

There is a very strong chance that Microsoft will deploy its Linux userspace before this project actually catches up for windows. I base this on that they've already released their alpha, and that they expect to release proper this summer.

http://www.theverge.com/2016/3/30/11331014/microsoft-windows-linux-ubuntu-bash

[CatsMiaow]

+1

[amcsi]

Note guys that the windows bash thing will require Hyper-V and thus Pro edition. People with Home edition won't be able to use it.

[cameron-martin]

I tried using flow with the linux-on-windows thing at work, but ide integration was a bitch because file paths need to be translated. Unless I run my ide from linux too, which could actually work.

[dallonf]

@amcsi Where did you get that information? I was under the impression that there was no virtualization involved; only a new subsystem. (See this blog post) Are you thinking of the Docker for Windows beta maybe?

In any case, depending on Bash for Windows seems like more of a stopgap; it's still fairly isolated from the rest of the system. You can benefit from typechecking, but editor plugins for auto-complete, tooltipls, and inline type checking (some of the huge benefits of Flow) aren't going to work very well with Bash.

[amcsi]

@dallonf there's no virtualization for Docker for Windows either as far as I know, but you still need Hyper-V for some reason. Don't quote me on this though.

Oh wait actually I think you are right, I did mix it up with Docker for Windows. With Windows Bash there's a more minor issue in that I would need to be logged into a Microsoft account when my current account is a non-Microsoft one. I'll actually try to change that if I can somehow.

[fhelwanger]

Is there any update on this? I'd really like to use flow in some projects that need to run on Windows.

[TimMensch]

I gave up. I'm now using TypeScript. At this point TypeScript supports everything I wanted from Flow, and TypeScript has _far_ better cross platform support.

[fhelwanger]

But its binaries are outdated and I don't know if they will be maintained in the future, so its very risky to adopt Flow on a large project that need to run on Windows.

[trinitroglycerin]

At the very best, then, TypeScript is the lesser of two evils as it has it's own share of problems.

[ghost]

From WebStorm 12 Roadmap:

further Flow integration (if it becomes available for Windows)
...
We are thinking about deeper integrating Flow with our editor, but we don’t think it’s worth proceeding before Flow supports Windows – most of our users are on Windows.

Can't blame them, since the last commit to https://github.com/OCamlPro/flow is now more than half a year ago.

Flowtype is an amazing feat of software engineering, the best type inference I've ever seen; but its governance & management is horrible.

[webuniverseio]

As a side note it might be worth to check babel plugin which turns flow type annotations into runtime checks. I know it works different than flow, but idea is quite interesting - https://github.com/codemix/babel-plugin-typecheck.

[bjrmatos]

A lot of activity in twitter about windows support, so an official response from the team would be very appreciated 😃

[JuHwon]

+

[MoOx]

Another weird "workaround" is to rely on this babel plugin https://github.com/codemix/babel-plugin-typecheck to use the flow notation to provide a similar static checking (and also can be done on runtime). Better than nothing.

Until Flow has official Windows binaries (and I am seeing someone assigned a few days ago \o/), the best solution seems to use the docker image https://github.com/motiz88/flow-docker since windows bins are tricky and even more out of date than the docker images.

[cristian-sima]

+1

[oviava]

You can build the latest version directly with OCAML win: https://gist.github.com/oviava/9c7f0a5ec2fdcdc737b0a75239e6546f

[gabelevi]

@oviava - yep, as you've noticed Windows support is getting closer! It builds and mostly works, but I wouldn't recommend it quite yet.

[MoOx]

I successfully build flow on windows too (wasn't able 2 days ago) so there is definetly good stuff coming.
Way faster than via docker.
Thanks @gabelevi (& the potential other involved) for the hard work (saying this cause you are assigned ^^).

[MoOx]

I just published an unofficial Flow Windows binary (based on master branch so sort of ~0.27)

https://gist.github.com/MoOx/2eabc75477a80b4dd137d0d8cb16f95d

I will try to keep it up to date until this issue is closed.

[cecilemuller]

@MoOx That's great, although you may want to move the download to another site than Sendspace because Windows Defender flagged the zip as a virus :/

[MoOx]

@cecilemuller Any recommendation? I don't usually send zip online :D

[cecilemuller]

@MoOx Dropbox , Google Drive or Github Releases should work :)

[MoOx]

I updated the gist with a link to a Google Drive folder where I will push builds :)

[cecilemuller]

Awesome :)

[trinitroglycerin]

Works a charm :+1:

[StoneCypher]

What @MoOx is doing is awesome

However we still really need an official build from @OCamlPro-Bozman or @OCamlPro-Henry so that @sindresorhus will push Windows support into the official NPM stuff.

[MoOx]

flow-bin are currently handled by flow team members.
So it's simple: an official build can be expected when this issue will be closed.

That's why I published this unofficial build (I just integrated a team that mostly work on windows and I don't want to wait - I can't live without flow now I tried).

[StoneCypher]

Thanks. That's why I opened the issue, and why I raised it here again today - to make sure that people remember there's still a big goal ahead for serious windows dev

[gabelevi]

Good news everyone! Windows support is here! Huge props to the OCamlPro team for their great work porting the tricky parts of Flow to Windows!

It's my great pleasure to finally close out this issue! If anyone finds bugs in the Windows binary, please create new issues!

[StoneCypher]

@gabelevi - Thank you kindly

[csvan]

@gabelevi thank you so much for the awesome work! You guys and the OCaml team are amazing <3