New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for TypeScript definition files #7

Open
mbektimirov opened this Issue Nov 18, 2014 · 49 comments

Comments

Projects
None yet
@mbektimirov

mbektimirov commented Nov 18, 2014

After the first look on Flow I can say it is inlined Typescript. Are you planning to support .d.ts definitions to make type headers unified? And what about es6 state? Does flow support it?

@benjamingr

This comment has been minimized.

Show comment
Hide comment
@benjamingr

benjamingr Nov 18, 2014

Supporting importing of .d.ts could be awesome, even if it'd only work 95% of the time. Especially if the type system is easier to migrate to than with TS (kind of like PHP and hack)

What do you mean by ES6 state?

benjamingr commented Nov 18, 2014

Supporting importing of .d.ts could be awesome, even if it'd only work 95% of the time. Especially if the type system is easier to migrate to than with TS (kind of like PHP and hack)

What do you mean by ES6 state?

@cirocosta

This comment has been minimized.

Show comment
Hide comment
@cirocosta

cirocosta Nov 18, 2014

Contributor

Regarding ES6, there's something on their blog post: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/#compatibility

It already supports various ES6 features such as destructuring, classes, extended objects, optional function parameters, and core API extensions (e.g., Map, Set, Promise, and new methods on Object, Array, and Math). Other features (notably modules) are on the way. Flow supports modules organized following the CommonJS / Node.js specification.

Contributor

cirocosta commented Nov 18, 2014

Regarding ES6, there's something on their blog post: https://code.facebook.com/posts/1505962329687926/flow-a-new-static-type-checker-for-javascript/#compatibility

It already supports various ES6 features such as destructuring, classes, extended objects, optional function parameters, and core API extensions (e.g., Map, Set, Promise, and new methods on Object, Array, and Math). Other features (notably modules) are on the way. Flow supports modules organized following the CommonJS / Node.js specification.

@avikchaudhuri

This comment has been minimized.

Show comment
Hide comment
@avikchaudhuri

avikchaudhuri Nov 18, 2014

Contributor

This is on our short-term todo list. See http://flowtype.org/docs/coming-soon.html#_

Contributor

avikchaudhuri commented Nov 18, 2014

This is on our short-term todo list. See http://flowtype.org/docs/coming-soon.html#_

@samwgoldman samwgoldman changed the title from Support for typescript and es6 to Support for TypeScript definition files Jun 24, 2015

@samwgoldman

This comment has been minimized.

Show comment
Hide comment
@samwgoldman

samwgoldman Jun 24, 2015

Member

I'm going to split off the ES6 part of the original question into another issue & merge other TypeScript-related issues with this one.

Member

samwgoldman commented Jun 24, 2015

I'm going to split off the ES6 part of the original question into another issue & merge other TypeScript-related issues with this one.

@0xR

This comment has been minimized.

Show comment
Hide comment
@0xR

0xR Jun 26, 2015

+1 This would make flow a lot more viable as a type checking system for our production code.

0xR commented Jun 26, 2015

+1 This would make flow a lot more viable as a type checking system for our production code.

jeffmo pushed a commit to jeffmo/flow that referenced this issue Jul 31, 2015

Jeff Morrison Jeff Morrison
Merge pull request #7 from syranide/xjsns
Add support for XML/XJS identifier namespaces
@clentfort

This comment has been minimized.

Show comment
Hide comment
@clentfort

clentfort Oct 20, 2015

Contributor

Is there any progress/roadmap on this issue?

Contributor

clentfort commented Oct 20, 2015

Is there any progress/roadmap on this issue?

@gcazaciuc

This comment has been minimized.

Show comment
Hide comment
@gcazaciuc

gcazaciuc Oct 22, 2015

Is "flow convert" command currently considered usable ? I'm not sure if there is currently an official way to convert .d.ts files but i know there has been some work into supporting this kind of conversion.

gcazaciuc commented Oct 22, 2015

Is "flow convert" command currently considered usable ? I'm not sure if there is currently an official way to convert .d.ts files but i know there has been some work into supporting this kind of conversion.

@gitawego

This comment has been minimized.

Show comment
Hide comment
@gitawego

gitawego Oct 29, 2015

that would be much better for third party definitions, with a simple tsd install react --save, I could easily use either flowtype or typescript

gitawego commented Oct 29, 2015

that would be much better for third party definitions, with a simple tsd install react --save, I could easily use either flowtype or typescript

@mattmo

This comment has been minimized.

Show comment
Hide comment
@mattmo

mattmo Dec 2, 2015

Wanted to bump this again since it's been over a month with no response. Is this in progress at all? Are there reasons for it not being in progress? Is this a good candidate for someone in the community to build?

mattmo commented Dec 2, 2015

Wanted to bump this again since it's been over a month with no response. Is this in progress at all? Are there reasons for it not being in progress? Is this a good candidate for someone in the community to build?

@dumconstantin

This comment has been minimized.

Show comment
Hide comment
@dumconstantin

dumconstantin Dec 2, 2015

+1
to have this implemented. Until then, is there any repo with Flow declaration files? At least for common things like mocha, gulp, etc.

I found this https://github.com/ptmt/flow-declarations, and it seems to have a lot of work done but there's no activity for the past 11 months...

dumconstantin commented Dec 2, 2015

+1
to have this implemented. Until then, is there any repo with Flow declaration files? At least for common things like mocha, gulp, etc.

I found this https://github.com/ptmt/flow-declarations, and it seems to have a lot of work done but there's no activity for the past 11 months...

@jeffmo

This comment has been minimized.

Show comment
Hide comment
@jeffmo

jeffmo Dec 9, 2015

Member

Update: We've spent some time circling our options and here's where we're at:

There are two perspectives we have to consider when approaching this problem: Library-definition authors (who would prefer to write a single library definition rather than two) and library-definition consumers (who would like to have somewhere like DefinitelyTyped to go and grab or contribute to a pre-existing libdef).

At the moment the biggest blocker to supporting .d.ts outright is the number of differences (both past and future) between the two systems. Nullability is one issue, nominal/structural subtyping is a second, there are others still. If we don't address these things carefully then library authors will find it difficult to write libdefs that work well in both systems and library consumers will have a difficult time figuring out which .d.ts files are best suited for whichever typechecker they are using.

So the options for dealing with this are as follows:

(a) Have Flow consume only libdefs that contain the most common subset of features and error on any features or syntax that don't properly map to Flow.

Given differing features as pervasive as nullability, nominal (vs structural) type annotations, some of Flow's built-in types like Class and mixed, etc: It's pretty clear this would not be a very practical option. In all likelihood we'd end up with a constrained subset leaving the best option for many libdef authors as just writing system-specific definition formats in order to be maximally expressive. At this point we're back to square one with our two formats :(

(b) Have Flow parse .d.ts files and just ignore any features that Flow doesn't understand or that don't map well to Flow's version of the feature.

This is problematic when any features that Flow has to ignore are vital to the interface definition (type-guard functions in TS are one example, nominal vs structural class types is another, lack of nullibility intent in the syntax is yet another). As a result the interface definition ends up working very well with one system and very poorly for the other.

(c) Built a best effort two-way converter between Flow libdefs and .d.ts files.

The purpose of this converter would be to take one format and do it's absolute best to convert to the other. Lossiness in the conversion would be expected (i.e. it wouldn't be able to predict the nullability characteristics of a type written for TypeScript, etc), but the benefit is that the output file can be tweaked and saved for future use.

(c) seems like our most practical option at the moment. It makes life easier for libdef authors who wish to support both systems and it makes it easy for libdef consumers to convert existing .d.ts files with minimal tweaking if some Flow library definition doesn't already exist.

I don't think the core Flow team will have enough time to work on a tool like this for at least the next several months, but it would be really cool to see something more refined than flow convert surface out of the community and beat us to it!

Member

jeffmo commented Dec 9, 2015

Update: We've spent some time circling our options and here's where we're at:

There are two perspectives we have to consider when approaching this problem: Library-definition authors (who would prefer to write a single library definition rather than two) and library-definition consumers (who would like to have somewhere like DefinitelyTyped to go and grab or contribute to a pre-existing libdef).

At the moment the biggest blocker to supporting .d.ts outright is the number of differences (both past and future) between the two systems. Nullability is one issue, nominal/structural subtyping is a second, there are others still. If we don't address these things carefully then library authors will find it difficult to write libdefs that work well in both systems and library consumers will have a difficult time figuring out which .d.ts files are best suited for whichever typechecker they are using.

So the options for dealing with this are as follows:

(a) Have Flow consume only libdefs that contain the most common subset of features and error on any features or syntax that don't properly map to Flow.

Given differing features as pervasive as nullability, nominal (vs structural) type annotations, some of Flow's built-in types like Class and mixed, etc: It's pretty clear this would not be a very practical option. In all likelihood we'd end up with a constrained subset leaving the best option for many libdef authors as just writing system-specific definition formats in order to be maximally expressive. At this point we're back to square one with our two formats :(

(b) Have Flow parse .d.ts files and just ignore any features that Flow doesn't understand or that don't map well to Flow's version of the feature.

This is problematic when any features that Flow has to ignore are vital to the interface definition (type-guard functions in TS are one example, nominal vs structural class types is another, lack of nullibility intent in the syntax is yet another). As a result the interface definition ends up working very well with one system and very poorly for the other.

(c) Built a best effort two-way converter between Flow libdefs and .d.ts files.

The purpose of this converter would be to take one format and do it's absolute best to convert to the other. Lossiness in the conversion would be expected (i.e. it wouldn't be able to predict the nullability characteristics of a type written for TypeScript, etc), but the benefit is that the output file can be tweaked and saved for future use.

(c) seems like our most practical option at the moment. It makes life easier for libdef authors who wish to support both systems and it makes it easy for libdef consumers to convert existing .d.ts files with minimal tweaking if some Flow library definition doesn't already exist.

I don't think the core Flow team will have enough time to work on a tool like this for at least the next several months, but it would be really cool to see something more refined than flow convert surface out of the community and beat us to it!

@dumconstantin

This comment has been minimized.

Show comment
Hide comment
@dumconstantin

dumconstantin Dec 9, 2015

Nice breakdown of the situation, thank you!

I've been digging a bit and came to the conclusion (which can be completely wrong, please correct me!) that Typescript and Flow serve different purposes:

Typescript: developer productivity and structure
Flow: dynamic program analysis (although the initial scope was different in Facebook's ecosystem)

The above describes a concurrent situation instead of a competing one. As such, compatibility between them is something for the Flow and Typescript teams to agree on and not the developers.

My understanding is that the two are compatible syntax wise and a program written in either (disregarding the definition files) should be parsable by both.

In my opinion both libraries should define a common standard (and maybe other typecheckers can emerge from that) for how types should be used in JavaScript. (dunno if one exists)

Type declaration is very much up to how each engine is implemented (and geared at serving the purpose of those engines as defined above) so I don't see (ever) a Flow <-> Typescript converter with a 100% match.

I'm looking forward to the next generation of analysis tools that will emerge from Flow and as for .d.ts, they seem to become the standard due to Typescript's much richer syntax for type declaration and community adoption.

In the meantime, I tried using Flow but without a massive investment in time for writing declaration files for all the libraries I use it doesn't provide much value.

What I did eventually is have Typescript just type checking and keep webpack/babel etc for transpiling my code (using gulp):

gulp.task('typecheck', function () {
  return gulp.src('src/**/*')
      .pipe(ext_replace('.tsx', '.js'))
      .pipe(ts()) //typescript gulp plugin
});

If ever Flow changes direction and supports .d.ts declarations I can just change the ts() call with a flow() one without any change to my codebase.

dumconstantin commented Dec 9, 2015

Nice breakdown of the situation, thank you!

I've been digging a bit and came to the conclusion (which can be completely wrong, please correct me!) that Typescript and Flow serve different purposes:

Typescript: developer productivity and structure
Flow: dynamic program analysis (although the initial scope was different in Facebook's ecosystem)

The above describes a concurrent situation instead of a competing one. As such, compatibility between them is something for the Flow and Typescript teams to agree on and not the developers.

My understanding is that the two are compatible syntax wise and a program written in either (disregarding the definition files) should be parsable by both.

In my opinion both libraries should define a common standard (and maybe other typecheckers can emerge from that) for how types should be used in JavaScript. (dunno if one exists)

Type declaration is very much up to how each engine is implemented (and geared at serving the purpose of those engines as defined above) so I don't see (ever) a Flow <-> Typescript converter with a 100% match.

I'm looking forward to the next generation of analysis tools that will emerge from Flow and as for .d.ts, they seem to become the standard due to Typescript's much richer syntax for type declaration and community adoption.

In the meantime, I tried using Flow but without a massive investment in time for writing declaration files for all the libraries I use it doesn't provide much value.

What I did eventually is have Typescript just type checking and keep webpack/babel etc for transpiling my code (using gulp):

gulp.task('typecheck', function () {
  return gulp.src('src/**/*')
      .pipe(ext_replace('.tsx', '.js'))
      .pipe(ts()) //typescript gulp plugin
});

If ever Flow changes direction and supports .d.ts declarations I can just change the ts() call with a flow() one without any change to my codebase.

@dckc

This comment has been minimized.

Show comment
Hide comment
@dckc

dckc Dec 11, 2015

Contributor

Regarding delegating to the community, i.e. option (c), would the core developers be willing to take care of the lexical details? i.e. add "flow parse" and "flow serialize" that read and write an AST in JSON format along the lines of https://github.com/estree/estree ?

Maybe this already exists?

Given that level of support, I can see myself tackling special cases of the "flow convert" problem as a way of exploring the design space.

Contributor

dckc commented Dec 11, 2015

Regarding delegating to the community, i.e. option (c), would the core developers be willing to take care of the lexical details? i.e. add "flow parse" and "flow serialize" that read and write an AST in JSON format along the lines of https://github.com/estree/estree ?

Maybe this already exists?

Given that level of support, I can see myself tackling special cases of the "flow convert" problem as a way of exploring the design space.

@dckc

This comment has been minimized.

Show comment
Hide comment
@dckc

dckc Dec 11, 2015

Contributor

Looks like getting an AST for a .d.ts file is supported.

Contributor

dckc commented Dec 11, 2015

Looks like getting an AST for a .d.ts file is supported.

@jeffmo

This comment has been minimized.

Show comment
Hide comment
@jeffmo

jeffmo Dec 11, 2015

Member

@dckc: There is flow ast which will emit a JSON ESTree* AST given some file content.

* Two minor caveats to calling the output "ESTree": 1) Flow obviously has syntax extensions, so those extensions are a part of the structure and 2) Some of the details of the ast are probably a bit outdated per the latest version of the ESTree spec (i.e. I think we still have old-style nodes for import/export, there are probably other things that could be more up to date). Otherwise the ast is just a JSON representation of the same AST Flow uses internally, so it's guaranteed to be complete.

Since flow ast taps Flow's internal parser directly, it's probably your most sure-fire way to parse any Flow code, but it's also worth noting that there is also Babylon (Babel's parser) which we are fairly dependent on for purposes of general transforms. So Babylon + babel-plugin-syntax-flow would be another option for parsing Flow-inclusive syntax that tracks the internal Flow parser very closely

Member

jeffmo commented Dec 11, 2015

@dckc: There is flow ast which will emit a JSON ESTree* AST given some file content.

* Two minor caveats to calling the output "ESTree": 1) Flow obviously has syntax extensions, so those extensions are a part of the structure and 2) Some of the details of the ast are probably a bit outdated per the latest version of the ESTree spec (i.e. I think we still have old-style nodes for import/export, there are probably other things that could be more up to date). Otherwise the ast is just a JSON representation of the same AST Flow uses internally, so it's guaranteed to be complete.

Since flow ast taps Flow's internal parser directly, it's probably your most sure-fire way to parse any Flow code, but it's also worth noting that there is also Babylon (Babel's parser) which we are fairly dependent on for purposes of general transforms. So Babylon + babel-plugin-syntax-flow would be another option for parsing Flow-inclusive syntax that tracks the internal Flow parser very closely

@dckc

This comment has been minimized.

Show comment
Hide comment
@dckc

dckc Dec 13, 2015

Contributor

I'm more interested in converting from .d.ts files to flow definitions than the other way around (since .d.ts files are more widely available and the flow type system is better in some critical ways). Is there a dual of flow ast that consumes JSON and produces flow declarations?

Contributor

dckc commented Dec 13, 2015

I'm more interested in converting from .d.ts files to flow definitions than the other way around (since .d.ts files are more widely available and the flow type system is better in some critical ways). Is there a dual of flow ast that consumes JSON and produces flow declarations?

@jeffmo

This comment has been minimized.

Show comment
Hide comment
@jeffmo

jeffmo Dec 15, 2015

Member

@sebmck: Do you think the codegen utils in Babel that work with the Babylon AST would work for @dckc? If so, do you have any pointers to them?

I was thinking .d.ts AST -> Babylon AST -> codegen...

Member

jeffmo commented Dec 15, 2015

@sebmck: Do you think the codegen utils in Babel that work with the Babylon AST would work for @dckc? If so, do you have any pointers to them?

I was thinking .d.ts AST -> Babylon AST -> codegen...

@henridf

This comment has been minimized.

Show comment
Hide comment
@henridf

henridf Dec 23, 2015

Contributor

Is there a plan to support imports in libdefs? (Couldn't find anything in the issues). For example like the ones done here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/node/node.d.ts#L440

I bring this up here because it will otherwise be necessary to do the module resolution in this conversion utility. If it's going to happen soon in core flow, then the converter should just be able to pass through module imports.

Contributor

henridf commented Dec 23, 2015

Is there a plan to support imports in libdefs? (Couldn't find anything in the issues). For example like the ones done here: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/node/node.d.ts#L440

I bring this up here because it will otherwise be necessary to do the module resolution in this conversion utility. If it's going to happen soon in core flow, then the converter should just be able to pass through module imports.

@jeffmo

This comment has been minimized.

Show comment
Hide comment
@jeffmo

jeffmo Dec 24, 2015

Member

@henridf: I'd like to make declare module body toplevels more directly correlate with the possible toplevels in a normal ES module -- so yea, I think having import in there makes sense just as much as having export does.

Switching declare modules to use explicit exports will be a pretty reasonably-sized breaking change -- but I think we still have time for such changes since we don't have a huge libdef ecosystem yet.

Member

jeffmo commented Dec 24, 2015

@henridf: I'd like to make declare module body toplevels more directly correlate with the possible toplevels in a normal ES module -- so yea, I think having import in there makes sense just as much as having export does.

Switching declare modules to use explicit exports will be a pretty reasonably-sized breaking change -- but I think we still have time for such changes since we don't have a huge libdef ecosystem yet.

@bassettsj

This comment has been minimized.

Show comment
Hide comment
@bassettsj

bassettsj Feb 23, 2016

Contributor

Would love to work on getting some way of being able to use TypeScript definition files or starting a flow specific repository of declaration files. In the meantime, it is taking a long time, especially as a newbie, to start taking advantage of flow. I really hope this feature can be prioritized somehow. I think it is way beyond my means to be able to contribute a PR back for this though.

Thanks for all the great work!

Contributor

bassettsj commented Feb 23, 2016

Would love to work on getting some way of being able to use TypeScript definition files or starting a flow specific repository of declaration files. In the meantime, it is taking a long time, especially as a newbie, to start taking advantage of flow. I really hope this feature can be prioritized somehow. I think it is way beyond my means to be able to contribute a PR back for this though.

Thanks for all the great work!

@gregegan

This comment has been minimized.

Show comment
Hide comment
@gregegan

gregegan Feb 23, 2016

Please TypeScript definition files or a flow specific repository of declaration files!

gregegan commented Feb 23, 2016

Please TypeScript definition files or a flow specific repository of declaration files!

@bsr203

This comment has been minimized.

Show comment
Hide comment
@bsr203

bsr203 Mar 16, 2016

Anyone like me who is looking for an update on this may found this repo and discussion useful flow-typed/flow-typed#4

Also

https://github.com/marudor/flowInterfaces

bsr203 commented Mar 16, 2016

Anyone like me who is looking for an update on this may found this repo and discussion useful flow-typed/flow-typed#4

Also

https://github.com/marudor/flowInterfaces

@rattrayalex

This comment has been minimized.

Show comment
Hide comment
@rattrayalex

rattrayalex Jul 7, 2016

Flow seems like a generally better tool than TypeScript – it has better support for gradual typing and ties in with the terrific Babel ecosystem.

That said, TypeScript has a stronger community – DefinitelyTyped and the TypeScript IDE tools are incredible. It doesn't make much sense to go with Flow if you'll have to write all those definition files yourself for third party libraries.

What would it take for Flow to take advantage of DefinitelyTyped? Is this likely to be prioritized by the core team at Facebook?

rattrayalex commented Jul 7, 2016

Flow seems like a generally better tool than TypeScript – it has better support for gradual typing and ties in with the terrific Babel ecosystem.

That said, TypeScript has a stronger community – DefinitelyTyped and the TypeScript IDE tools are incredible. It doesn't make much sense to go with Flow if you'll have to write all those definition files yourself for third party libraries.

What would it take for Flow to take advantage of DefinitelyTyped? Is this likely to be prioritized by the core team at Facebook?

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Aug 3, 2016

Absence of ts2flow converter is going to kill flow, as typescript community gains momentum. The plans to release flow2ts don't make it better as it'll be even easier to switch from flow to typescript.

Instead, please make it easier to switch from "less sound" typescript system to "more sound" flow, by creating a definition converter, and let developers fill the blanks. Only then flow2ts converter makes any sense. As others stated, there aren't lot of people willing to replicate definitely typed efforts. Currently, with just flow2ts converter, there isn't much to convert from.

Introducing ts2flow converter could potentially bring this little list of flow definitions from 90 entries to 1900 in a matter of few weeks!

sheerun commented Aug 3, 2016

Absence of ts2flow converter is going to kill flow, as typescript community gains momentum. The plans to release flow2ts don't make it better as it'll be even easier to switch from flow to typescript.

Instead, please make it easier to switch from "less sound" typescript system to "more sound" flow, by creating a definition converter, and let developers fill the blanks. Only then flow2ts converter makes any sense. As others stated, there aren't lot of people willing to replicate definitely typed efforts. Currently, with just flow2ts converter, there isn't much to convert from.

Introducing ts2flow converter could potentially bring this little list of flow definitions from 90 entries to 1900 in a matter of few weeks!

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Aug 4, 2016

If anyone has time to implement this, I think the best way is to modify typescript's declarationEmitter to output flow declarations instead.

You can try d.ts -> ast -> d.ts conversion with following:

npm install -g typings typescript@next
typings install dt~jquery --save --global
cp typings/globals/jquery/index.d.ts index.ts
tsc -d index.ts
diff typings/globals/jquery/index.d.ts index.d.ts
# Results in a lot of style-only changes

After modifying declarationsEmitter you might achieve d.ts -> ast -> js.flow

sheerun commented Aug 4, 2016

If anyone has time to implement this, I think the best way is to modify typescript's declarationEmitter to output flow declarations instead.

You can try d.ts -> ast -> d.ts conversion with following:

npm install -g typings typescript@next
typings install dt~jquery --save --global
cp typings/globals/jquery/index.d.ts index.ts
tsc -d index.ts
diff typings/globals/jquery/index.d.ts index.d.ts
# Results in a lot of style-only changes

After modifying declarationsEmitter you might achieve d.ts -> ast -> js.flow

@amilajack

This comment has been minimized.

Show comment
Hide comment
@amilajack

amilajack Aug 21, 2016

@sheerun What do you mean by 'style-only changes'?

amilajack commented Aug 21, 2016

@sheerun What do you mean by 'style-only changes'?

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Aug 21, 2016

Different whitespace

sheerun commented Aug 21, 2016

Different whitespace

@amilajack

This comment has been minimized.

Show comment
Hide comment
@amilajack

amilajack Aug 21, 2016

But would the converted form still work correctly?

amilajack commented Aug 21, 2016

But would the converted form still work correctly?

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Aug 21, 2016

It converts d.ts to ast, and back to d.ts, so it works as intended.

A task to volunteer is to implement conversion from ast to js.flow.

sheerun commented Aug 21, 2016

It converts d.ts to ast, and back to d.ts, so it works as intended.

A task to volunteer is to implement conversion from ast to js.flow.

@amilajack

This comment has been minimized.

Show comment
Hide comment
@amilajack

amilajack Aug 21, 2016

@thejameskyle I've just saw your on comment on migrating typescript definitions to flow. Has anything changed since you posted that?

amilajack commented Aug 21, 2016

@thejameskyle I've just saw your on comment on migrating typescript definitions to flow. Has anything changed since you posted that?

@Kegsay

This comment has been minimized.

Show comment
Hide comment
@Kegsay

Kegsay Sep 21, 2016

Author of flow-jsdoc here: I might have a stab at writing an automatic converter from .d.ts to Flowtype. In most cases, 95% conversions are "good enough" and if you really care you can just hand roll after conversion. This works really well for my personal projects with JSDoc -> Flowtype annotations, so I imagine the same usefulness will apply here. Will pingback here if/when I get something usable.

Kegsay commented Sep 21, 2016

Author of flow-jsdoc here: I might have a stab at writing an automatic converter from .d.ts to Flowtype. In most cases, 95% conversions are "good enough" and if you really care you can just hand roll after conversion. This works really well for my personal projects with JSDoc -> Flowtype annotations, so I imagine the same usefulness will apply here. Will pingback here if/when I get something usable.

@mweststrate

This comment has been minimized.

Show comment
Hide comment
@mweststrate

mweststrate Nov 2, 2016

@Kegsay any update on the converter?

mweststrate commented Nov 2, 2016

@Kegsay any update on the converter?

@bsr203

This comment has been minimized.

Show comment
Hide comment
@bsr203

bsr203 commented Nov 2, 2016

@mweststrate I see this on the author'ss github page https://github.com/Kegsay/ProbablyFlowTyped

@mweststrate

This comment has been minimized.

Show comment
Hide comment
@mweststrate

mweststrate Nov 2, 2016

Feeling stupid now :) Thanks!

mweststrate commented Nov 2, 2016

Feeling stupid now :) Thanks!

@Kegsay

This comment has been minimized.

Show comment
Hide comment
@Kegsay

Kegsay Nov 3, 2016

I haven't announced it yet since it really is still a WIP - It barely works :)

Kegsay commented Nov 3, 2016

I haven't announced it yet since it really is still a WIP - It barely works :)

@joarwilk

This comment has been minimized.

Show comment
Hide comment
@joarwilk

joarwilk Nov 18, 2016

I had a go at it here: https://github.com/joarwilk/flowgen

It's somewhat close to being finished and all help is appreciated - I'll add the remaining things as issues as soon as I can. There's a couple of not-super-trivial definitions it can translate with 100% accuracy, but it still struggles with most cases.

It's based on d.ts -> ast -> flow as discussed above.

joarwilk commented Nov 18, 2016

I had a go at it here: https://github.com/joarwilk/flowgen

It's somewhat close to being finished and all help is appreciated - I'll add the remaining things as issues as soon as I can. There's a couple of not-super-trivial definitions it can translate with 100% accuracy, but it still struggles with most cases.

It's based on d.ts -> ast -> flow as discussed above.

@Kegsay

This comment has been minimized.

Show comment
Hide comment
@Kegsay

Kegsay Nov 18, 2016

@joarwilk That sounds a lot more comprehensive than my one which I still haven't found time to work on. I'm more than happy for someone other than me to do this: though it would be nice to get some tests in there. You should just be able to thieve the test runner and drop in the .d.ts and .js.flow files in defs, running it using this command. Thank you for your hard work on it!

Kegsay commented Nov 18, 2016

@joarwilk That sounds a lot more comprehensive than my one which I still haven't found time to work on. I'm more than happy for someone other than me to do this: though it would be nice to get some tests in there. You should just be able to thieve the test runner and drop in the .d.ts and .js.flow files in defs, running it using this command. Thank you for your hard work on it!

@joarwilk

This comment has been minimized.

Show comment
Hide comment
@joarwilk

joarwilk Nov 18, 2016

@Kegsay Yeah adding tests would be super beneficial, the problem with that solution though is that I don't actually know what the flowtype exports are going to look like. It's a very experimental phase.

It'd be interesting to use the test runner + tests from flow-typed and use those as a benchmark.

joarwilk commented Nov 18, 2016

@Kegsay Yeah adding tests would be super beneficial, the problem with that solution though is that I don't actually know what the flowtype exports are going to look like. It's a very experimental phase.

It'd be interesting to use the test runner + tests from flow-typed and use those as a benchmark.

@andreawyss

This comment has been minimized.

Show comment
Hide comment
@andreawyss

andreawyss Dec 12, 2016

When will it be possible to generate all the necessary TypeScript Definition files from the Flow definitions of a ES6 library project?

andreawyss commented Dec 12, 2016

When will it be possible to generate all the necessary TypeScript Definition files from the Flow definitions of a ES6 library project?

@joarwilk

This comment has been minimized.

Show comment
Hide comment
@joarwilk

joarwilk Jan 4, 2017

@andreawyss have you tried running tsc -d on your library files? Works decently for me.

Regarding TS->Flow: I have updated my repo and moved it to https://github.com/joarwilk/flowgen.

There's a PR to flow-typed here which shows the current state of the converter.

joarwilk commented Jan 4, 2017

@andreawyss have you tried running tsc -d on your library files? Works decently for me.

Regarding TS->Flow: I have updated my repo and moved it to https://github.com/joarwilk/flowgen.

There's a PR to flow-typed here which shows the current state of the converter.

@btipling

This comment has been minimized.

Show comment
Hide comment
@btipling

btipling Mar 7, 2017

As Flow supports and sometimes requires variance annotation and TypeScript does not, I doubt that a converter could be successful in all cases. I think that such a converter would at least sometimes not find enough information in a typescript definition file to satisfy flow's compiler requirements.

btipling commented Mar 7, 2017

As Flow supports and sometimes requires variance annotation and TypeScript does not, I doubt that a converter could be successful in all cases. I think that such a converter would at least sometimes not find enough information in a typescript definition file to satisfy flow's compiler requirements.

@sheerun

This comment has been minimized.

Show comment
Hide comment
@sheerun

sheerun Jul 1, 2017

As I suspected, devs are choosing TypeScript instead of Flow because of DefinitelyTyped: https://redditblog.com/2017/06/30/why-we-chose-typescript/

sheerun commented Jul 1, 2017

As I suspected, devs are choosing TypeScript instead of Flow because of DefinitelyTyped: https://redditblog.com/2017/06/30/why-we-chose-typescript/

@rattrayalex

This comment has been minimized.

Show comment
Hide comment
@rattrayalex

rattrayalex Jul 7, 2017

rattrayalex commented Jul 7, 2017

@vojtatranta

This comment has been minimized.

Show comment
Hide comment
@vojtatranta

vojtatranta Nov 21, 2017

Babel can read Typescript https://medium.com/@jdolle/babel-7-beta-instructions-aed5cf17048b

Then we could use Babylon to convert it to AST and them analyze it with flow or not?

vojtatranta commented Nov 21, 2017

Babel can read Typescript https://medium.com/@jdolle/babel-7-beta-instructions-aed5cf17048b

Then we could use Babylon to convert it to AST and them analyze it with flow or not?

@idanilt

This comment has been minimized.

Show comment
Hide comment
@idanilt

idanilt Dec 4, 2017

I am keep straggling with this issue, when I am creating a lib and I need to support TS & flow I end up maintaining two definition manually
I searched and searched the web and didn't find anything solving me this problem.

If anybody can shade some light on this issue it will be amusing

idanilt commented Dec 4, 2017

I am keep straggling with this issue, when I am creating a lib and I need to support TS & flow I end up maintaining two definition manually
I searched and searched the web and didn't find anything solving me this problem.

If anybody can shade some light on this issue it will be amusing

@mrkev

This comment has been minimized.

Show comment
Hide comment
@mrkev

mrkev Sep 10, 2018

Contributor

This project goes the other direction, but might be helpful as reference https://github.com/bcherny/flow-to-typescript/tree/recursive-descent

Contributor

mrkev commented Sep 10, 2018

This project goes the other direction, but might be helpful as reference https://github.com/bcherny/flow-to-typescript/tree/recursive-descent

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