Turf: Flow Support

[Meberem]

I noticed in this comment that flow support might be added once typescript definitions had been completed. Is this still the case?

[DenisCarriere]

@Meberem At the moment Flow hasn't been implemented in TurfJS, however... if you propose a plan on how to implement Flow into TurfJS I'm willing to help out. Last time I tried to tackle Flow support it was getting too complicated to implement.

Typescript was fairly easy, simply had to include an index.d.ts to each repo without having to touch the source code index.js.

[Meberem]

Hi @DenisCarriere, this has been my experience with flow as well - rather complicated and ultimately unsuccessful. Very frustrating overall and I am not sure why

From my understanding it is possible to add a similar thing to index.d.ts for flow but as for implementing that I am not too sure.

I'll see if converting my project to typescript is a possibility. Thanks!

[DenisCarriere]

It's been a real challenge trying to support Flow (with an easy implementation).

They have flow-typed which is Flow's attempt of a index.d.ts, however to this date I still don't understand how to create a Flow definition.

Going to close this issue for now, feel free to open it again or submit a proposal on how you would implement this.

[NameFILIP]

Can this issue please be reopened?

There is this awesome comment from @jeffmo shedding some light onto how to ship type definitions with your project: https://github.com/facebook/flow/issues/1996#issuecomment-230919868 (I with it was better defined in the Flow's official docs)

P. S. We recently had a turf library version upgrade which had a breaking change (options are passed as an object) and it while it could have been caught by Flow, it wasn't due to a lack of type definitions.

[DenisCarriere]

There has been an attempt to implement type definitions using Typescript, but it made the project source code too complex and very time consuming to refactor TurfJS.

I doubt Turf will ever enforce type definitions.

[NameFILIP]

Faster refactor with more bugs is not necessarily better than a slower refactor with less bugs.

Also, are you taking into account the time spent to investigate, find and fix bugs by all users of the library?