
Flowtype 0.30 adds support for Windows - thejameskyle
https://www.flowtype.org/blog/2016/08/01/Windows-Support.html
======
thejameskyle
Hi HN, just wanted to let you know that the Flow team is watching this thread
and is happy to respond to any questions that you have :)

~~~
smt88
Any update on support for using TypeScript definition files with Flow? It
doesn't seem as though the team is still watching the issue on Github:
[https://github.com/facebook/flow/issues/7](https://github.com/facebook/flow/issues/7)

~~~
thejameskyle
We've actually been discussing going the other way with a conversion tool for
package publishers. Flow has a more sound type system and it's easier to
downgrade than upgrade.

The next few months should hopefully start seeing a lot of new tools for
managing and publishing types within the community. It would be great to see
more adoption from package owners themselves.

~~~
smt88
> _conversion tool for package publishers_

I'm not sure I understand how that's different from just supporting TypeScript
definitions. Couldn't the conversion tool just be built into Flow so that it
works transparently for the user? Or are you saying human intervention is
required?

> _Flow has a more sound type system_

Can you elaborate? What are the features of Flow that aren't present in
TypeScript and would result in lossy conversion?

~~~
thejameskyle
It's not a trivial task for either Flow or TypeScript to support definitions
of one another.

We've attempted to build a TS => Flow conversion tool, but it's much harder to
go in that direction because you have less guarantees.

You aren't going to find a lot of "features" that either one supports that the
other does not. However, many of TypeScript's implementations of the same
features are less strict even with all of the strict flags on.

Here's an example that came up just last week:
[https://gist.github.com/thejameskyle/24a4e32be4899419e53eec6...](https://gist.github.com/thejameskyle/24a4e32be4899419e53eec655e538a7f)
(Note: This is not a bug in TypeScript, it's a design decision)

Because Flow is more strict than TypeScript it's much easier to convert from
Flow definitions to TypeScript definitions.

~~~
thorn0asdf
It should be much easier to implement a "TS definition source files (.d.ts) =>
Flow" converter than generic "TS => Flow". The language in .d.ts is a small
subset of TS. Are your explanations about Flow's strictness really applicable
to this subset?

See
[https://github.com/Microsoft/TypeScript/blob/master/doc/spec...](https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md#111-programs-
and-source-files)

> Here's an example that came up just last week: [...] (Note: This is not a
> bug in TypeScript, it's a design decision)

I believe this design decision isn't final, but again: what difference does
this example make if we're talking just about type declarations?

~~~
smt88
I had these same thoughts, but I decided to just drop it. The Flow team
doesn't seem nearly as interested in usability/adoption as the TypeScript team
(perhaps an issue of resources/bandwidth). Even if I like Flow's philosophy
better and the type system was better-designed until recently, the TypeScript
community and ecosystem trump any benefits of Flow at this point.

~~~
thejameskyle
> The Flow team doesn't seem nearly as interested in usability/adoption as the
> TypeScript team

It makes me sad that you think this. The team cares very deeply about
usability and adoption. We've committed to making it our sole focus for the
current half. I was brought onto the team to focus on the external experience
and adoption because of my experience working on Babel.

We're solving a very difficult problem space, and we're doing our best to do
it right. Trust me that we're thinking about all the same things you are and
finding ways to address them.

Also, I must say that I agree that the TypeScript has a massive lead in the
community and ecosystem. It's just our opinion that we've set ourselves up to
do even better, we're just now switching modes from making the type checker
awesome to making the user experience awesome.

If you have any concerns about the experience we're happy to hear it. Having a
rapid constant feedback loop is important.

~~~
thorn0asdf
James, I'd be glad if you answered my pretty simple and specific questions
here:
[https://news.ycombinator.com/item?id=12209131](https://news.ycombinator.com/item?id=12209131)

------
jesseschalken
Am I correct in saying that the Hack and Flow typecheckers share a lot of
code? If so, does this mean that Hack typechecking on Windows could be next?

~~~
gabelevi
Yep, you are correct! The hardest parts of getting Flow and Hack to build on
Windows are solved. For Hack, there's probably a long tail of small issues
before a Windows build can be released, though.

Is Hack on Windows something that you'd use? Or are you asking out of
curiosity?

~~~
jesseschalken
It is. We have a large codebase we would like to migrate to Hack, but we also
have a lot of developers who use Windows and the current experience with
needing to boot a virtual machine just to check types doesn't really cut it.

