Skip to content
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

Facebook's own Flow adoption? #7365

Closed
jamesisaac opened this issue Jan 16, 2019 · 44 comments

Comments

@jamesisaac
Copy link
Collaborator

@jamesisaac jamesisaac commented Jan 16, 2019

(Apologies if this isn't appropriate usage of the issue tracker, feel free to close if so.)

Jest (another Facebook project) has recently announced they're planning on migrating their codebase from Flow to TypeScript: facebook/jest#7554

Quite surprised to see that decision go through, as I would have expected Facebook to just veto it for the obvious reason of internal cohesion/support between its own projects.

I'm personally more of a fan of Flow's approach of favouring correctness. A lot of my confidence in continuing to use Flow in my projects is that it's backed by Facebook's usage for its own projects (React, RN, Relay, Metro etc). But given that there's seemingly no opposition to a FB project, not even just being started in TS but being actively rewritten off of Flow, it brings this view into question. And of course, the linked issue is now being paraded all over HN, Reddit, etc, raising further FUD against Flow.

Is there any chance someone on the Facebook team could outline the company's long term plan for type system usage? Is Jest somehow an exception, and React/RN/Facebook's own internal codebases etc are firmly committed as Flow projects? Or is Facebook internally beginning to consider migrating away? From what I understand, every change to Flow's codebase has to be approved by someone employed by Facebook, so having an idea of how much attention FB will be directing towards Flow seems fairy crucial to understanding its long term prospects.

And I guess a further question is whether Flow is planning on prioritising the main issues people keep bringing up when discussing reasons to migrate away (support for 3rd party type definitions, stability of the type checker).

@hewsut

This comment has been minimized.

Copy link

@hewsut hewsut commented Jan 16, 2019

Yeah, big +1 on this. I just finished an upgrade in a product at our company to beyond 0.85 this morning and the timing on that juxtaposed with the news would be hilarious if it wasn't so painful.

Some more vision on Flow future would be 💯 right now.

@eleith

This comment has been minimized.

Copy link
Contributor

@eleith eleith commented Jan 16, 2019

related discussion here about desiring a public roadmap or vision for the future: #6833

@jamesisaac

This comment has been minimized.

Copy link
Collaborator Author

@jamesisaac jamesisaac commented Jan 16, 2019

Another recent example I encountered is from the React Native website, the Getting Started guide begins by recommending to build with Expo (so not an official Facebook product, but heavily endorsed), which also decided to migrate to TS (expo/expo#2164) and is now even actively recommending users against using Flow in their own codebases (expo/expo#3069).

So the official onboarding for React Native has now become to use TypeScript. Which is strange considering Facebook does seem to be putting a lot of effort into further improving RN's Flow typings (facebook/react-native#22100), and doesn't even officially export any TS typedefs for RN.

@villesau

This comment has been minimized.

Copy link
Collaborator

@villesau villesau commented Jan 16, 2019

This is very interesting topic! The latest news without comments from FB affects the community. Uncertainty easily eats the motivation and makes you think wether it is worth the effort to invest time in Flow community.

For example, there are plans to migrate flow-typed to Lerna & publishing the libdefs in NPM. We probably do it nevertheless, but knowing Facebooks commitment would be highly motivating.

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 16, 2019

I'm on the Flow team. These are my own views, so don't take this to represent FB or the Flow team in general. @avikchaudhuri is planning some communication around the Flow team's recent work and our plans in the next week or so.

Personally, I believe that Flow's focus on soundness (an explicit non-goal for TypeScript) means that there will continue to be a place for it. Of course, we have some holes in our type system but we continue to work to fix them. Soundness is especially important for large projects, or projects which have a particularly high quality bar. Facebook's main JS codebases continue to use Flow, and I don't see any evidence that that will change. I wouldn't read too much into one relatively small, isolated project switching over. Different projects have different needs, and that's fine.

I think we have an exciting year ahead. For a long time, we have been hardly able to keep up with the needs of Facebook, and that has led us to neglect the open source community. However, the team has grown significantly in the last six months or so, and we are close to wrapping up several important performance projects. I'm optimistic that we will be able to find the time to engage more with you all in the future.

I'm going to close this because I think I have answered your question. Feel free to reopen or just reply if you need additional clarification.

@nmote nmote closed this Jan 16, 2019
@satya164

This comment has been minimized.

Copy link

@satya164 satya164 commented Jan 17, 2019

@nmote are there any plans to publish a roadmap of some kind? It would be super helpful if people know what's a priority for the team.

@jbrown215

This comment has been minimized.

Copy link
Contributor

@jbrown215 jbrown215 commented Jan 17, 2019

@satya164 yes

@jamesisaac

This comment has been minimized.

Copy link
Collaborator Author

@jamesisaac jamesisaac commented Jan 17, 2019

Thanks for your response @nmote , it's really encouraging to hear that the Flow team has grown, and that you're optimistic about being able to engage more with Flow users outside of Facebook. There have been some great features landing in Flow the past year, so definitely excited to see what's coming in 2019.

I wouldn't read too much into one relatively small, isolated project switching over. Different projects have different needs, and that's fine.

It might be worth this being communicated a bit more, as the general impression in all the discussion threads I saw over Jest's migration was "the writing's on the wall, Facebook is making an official move away from Flow", with no one stepping in to say otherwise. Jest is under the FB org, presumably used internally throughout FB, and the type of project you'd expect to strive for soundness (a test framework)... so the nuance that it's "relatively small and isolated" wouldn't be particularly obvious to people outside of FB. The announcement just came across as pretty bad PR for Flow, and ironically not from a competitor or anything, but from another FB project...

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 17, 2019

Again, speaking just for myself, not for the rest of the team and the company. I don't know what went into the Jest decision, but from a look at the recent history of the repository it appears that maintenance has been turned over to someone who does not appear to be an FB employee. Absent something like malicious or incompetent behavior, I believe that active maintainers should have authority over their project, regardless of what org it is under. I don't think it would be right for Facebook to veto their technical decisions for basically political purposes. I agree that it looks bad but again, I wouldn't read too much into it.

I'll see if @avikchaudhuri can address this point as well in his more official roadmap post.

@debel27

This comment has been minimized.

Copy link

@debel27 debel27 commented Jan 19, 2019

Jest is under the FB org, presumably used internally throughout FB, and the type of project you'd expect to strive for soundness (a test framework)...

Ironically enough, testing is more about completeness than about soundness (as pointed out by the Flow documentation). Maybe this migration from Jest is only fitting, after all !

Joke aside, it's great to read that the Flow team just got bigger and plans to interact more with the community. Looking forward to it !

@pascalduez

This comment has been minimized.

Copy link
Contributor

@pascalduez pascalduez commented Jan 19, 2019

Thanks for starting that thread @jamesisaac, and thanks for the replies @nmote @jbrown215.

Indeed it's a bit of a rough period for Flow users currently. Although I tend not to follow trends and always take announces and moves with a grain of salt.

There was a worrying change as well with the abandon of Nuclide.
What's the future of ide-flowtype then? Given that atom-ide-ui is already archived.
This Atom integration used (still) to work really well.
Being "forced" to switch editor to keep using Flow is a bit harsh.

What I try to point is we need to consider the whole ecosystem as well, because that's our daily routine: linters, compilers support and responsiveness (Babel, babel-eslint, react-docgen, ...).

@TrySound

This comment has been minimized.

Copy link
Collaborator

@TrySound TrySound commented Jan 19, 2019

@pascalduez Guys moved their forces into better flow lsp support so any editor with lsp could seamlessly integrate flow. I guess VSCode is the first in the list of editors now. There is also coming builtin lsp support in neovim (and good enough plugin). I think this is the right direction.

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 23, 2019

This is correct, we are going all-in on the LSP. It provides the best user experience and is quickly becoming a standard across editors. Unfortunately I don't have a good answer for how to continue using Atom with Flow, but https://github.com/atom/atom-languageclient might be a good start. I haven't tried it but the main contributor used to be on the Atom core team. Hopefully the Flow community can step up and fill in any remaining glue code needed between Flow and Atom.

@dnalborczyk

This comment has been minimized.

Copy link
Contributor

@dnalborczyk dnalborczyk commented Jan 24, 2019

Jest (another Facebook project) has recently announced they're planning on migrating their codebase from Flow to TypeScript

not trying to poor gasoline in the fire, but it seems another Facebook project is migrating as well: yarnpkg/yarn#6953

@arcanis

This comment has been minimized.

Copy link
Contributor

@arcanis arcanis commented Jan 24, 2019

Please note that Yarn is a community project before anything else (as evidenced by it being its own Github org). I'm the only Facebook engineer also active member of the core team 🙂

Also note that the switch wasn't prompted by any deficiency in Flow - we (as in, the Yarn org) simply try to shake things up in order to attract contributors. Maybe it'll work, maybe it won't, but this doesn't reflect in any way Facebook's investment in Flow.

@TrySound

This comment has been minimized.

Copy link
Collaborator

@TrySound TrySound commented Jan 24, 2019

Now tell this to every person on twitter who wrote that flow is dead. There are a lot if such tweets.

@PinkaminaDianePie

This comment has been minimized.

Copy link

@PinkaminaDianePie PinkaminaDianePie commented Jan 24, 2019

I'm really sorry to say that, but personally, for me Facebook has become #1 disappointment of 2018.

Good tool lost a war to the bad tool. It's not enough to have the best engineers, software in our days is a community around it. Facebook just threw away their community and it was the main reason why Flow lost to TS.

You lost Nuclide, then quite well-known tools dropped Flow in favor of TS, what will be next? Maybe we should try ReasonML? You know what? How we could trust FB after that? It can become dangerous to use FB tools, who knows, maybe I can start to use ReasonML today, but tomorrow it will be moved to the facebook-archive organization? How people can believe in FB tools and contribute to them? All development going behind closed doors, so no one can be sure that their contribution to "open source" will be thrown away. People will start to afraid of using all FB tools, not just flow. Of course, everyone will continue to use React, but if we speak about new and experimental technologies - less and less amount of people will be eager to contribute them and adapt. It will be harmful not only to Flow but to all FB projects more or less. Just imagine for a second - web developers trust Microsoft more than Facebook, a few years ago MS products (IE) was the pain in the ass, everyone remembers that, but still people trust MS more than FB. Isn't it a strong signal enough?

It's just unbelievable - it a beginning of 2019 and there are no good type systems for js.

  • TS is broken by design - type checking doesn't work, you can be never sure about type safety.
  • Flow will become a tool for nerds/freaks - the community will drop to a very small group of people, there will be no lib definitions even to popular libraries (community won't have enough capacity for that), there will be no people to ask for help in Discord etc.
  • ReasonML - totally not a JS, but a language which present itself as ES2020. Another tool from FB, so it's just dangerous to use it, no one will give you a guarantee that it will be abandoned tomorrow.
  • Haskell/PureScript, Elm, others - I just have 0 job positions around, so I won't be able to find a job.

Flow was a really promising thing, and I still think that it was the best attempt ever to "fix" javascript. But it doesn't really matter if no one will use it. My current company will likely migrate to TS soon as well, so I will be forced to switch to TS as well.

You can say lots of times that Flow is not dead and will grow, but who will read that if you write about that in GitHub issues? Where are Medium posts? Tweets? Public RFC? Q-and-A sessions in Reactiflux? Just anything? You told community month ago that you will share FB plans about Flow. In the meantime Jest and Yarn switched to TS. A lot of developers read about that on Twitter, Reddit, other places. And nothing from Flow. People read news about everyone moving to TS and no news from the Flow team. Just a few answers in the middle of one GitHub issue. Honestly, it would be better for you to hire not only developers but some people who will work with the community and create such posts, tweets, articles.

You promised us to work on your mistakes in 2019, but close to the end of the first month we can see only labels for issues (thx @jbrown215 for at least such thing), but that's it. You can say that there were holidays and vacations, but in the meantime, other projects were capable to start TS adoption and writing about that across the internet.

You can say about your other problems, about internal FB problems with performance, about the focus on internal needs, about high workload and inability to spend more time on public activity etc, but it won't matter at all. No one will read this issue. 36 likes for main post and 28 for the answer - that's all your community. And more of that, it will be still just words. You can promise a lot of stuff (which again no one will know about because there are no blog posts and tweets about that), but other projects will action. And for people actions + public discussions of these topics are much more important than words.

To be honest, I don't really know if it's not too late to do something and how many efforts FB will need to get back the attention of the community to Flow - probably it will be too expensive. I don't even know if anyone is interested in reading all that whining - there is no public goals and roadmap so I don't really know if FB interested in making Flow widely adopt outside of internal FB codebase. Maybe it's just a tool for internal use and it's enough to keep it alive, but no one interested in promoting it outside.

I just really upset that I'm lost good tool and will be forced to use bad tools. Of course, I will use Flow for pet projects until it will be moved to facebook-archive, but soon it will be harder to find a job position with Flow than job position with Haskell. I just have no choice but to use the bad tool instead of good one in daily coding. I won't convince anyone in any company to use Flow, while everyone else switches from Flow to TS. And again to be clear: I'm not the guy "I've struggled with Flow too much, so I've tried TS and love it, bye-bye Flow". Just vise versa - I've tried TS and it just doesn't work - it can't catch any errors and it's not even close to type safety. I really wanna continue to use Flow. But I can't, I just can't.

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 24, 2019

All I can really say is that this is fair criticism, and I'm doing everything I can to improve things. It looks like there is growing organizational support for increasing the time we spend doing things like merging pull requests and triaging issues. @avikchaudhuri is still working on finishing a plan for the rest of 2019, at which point he will publish it, probably on Medium. We'll also most likely increase our presence on other platforms, like Twitter or Slack. But it takes time to change habits, and I understand if you are out of patience waiting for us on this. I'm sorry to have disappointed you.

@PinkaminaDianePie

This comment has been minimized.

Copy link

@PinkaminaDianePie PinkaminaDianePie commented Jan 25, 2019

I really appreciate that you understood the issue, but I afraid that it can be too late. "at which point he will", "most likely" is not something that can stop that snowball effect from Yarn and Jest migration. It could help half a year ago, before all that changes, but right now average developer will move just because other well-known tools and companies move. The community will continue to decrease even after publishing a roadmap. The roadmap is nothing compared to Yarn and Jest. In the best case it will be "ok, I'm migrating right now because TS is much better, but maybe someday I'll give another chance to Flow if they will really work on their problems". Snowball effect is really underestimated, your tweets and articles could be lost in the middle of the hype train around "Typescript taking over the Facebook" topic. It already should be something much more serious than a bunch of tweets/articles. And time is really critical resource here - article today will give much more attention than article tomorrow. And an article in 2 months will be just useless, just because everyone will forget about flow existence. You could think "we need one more week" to polish everything - but in that week few more major libraries will migrate to TS and positive effect from the article will be already neglected by the fact that everyone moves. It's not anymore just about flow internal organization problems - it's snowball effect which is quite hard to stop, no matter how hard you will improve Flow and collaboration with the community. It's not even like starting from scratch - it's starting from the level below zero, because lots of developers remember hard times with Flow and will afraid to give it second chance. I could imagine lots of tweets around upcoming changes "when FB will stop beating the dead horse and migrate React to Typescript? everyone will be happy". It will be much harder to deal with it than anyone expects.

P.S.: @nmote, you never disappointed me (and other FB devs), I like Flow as a tool, and compared to TS it's much much better. The thing which disappointed me - management of all that stuff. Flow could be in much better shape right now if the community would have more attention, if there will be public roadmaps, RFC, blog posts etc, but it's not a developers fault. Development of Flow was behind closed doors without transparency and I doubt that it was pure developers decision. I hope FB management learned that lesson and understood that it's just not enough to hire bunch of good developers and create public open source project. It's totally enough for internal projects, but when you have competitors from other companies and wanna take over the community - you need to invest in it LOTS of time and money. It can't be done by developers alone. It should be a clear policy on a company level.

@ArmorDarks

This comment has been minimized.

Copy link

@ArmorDarks ArmorDarks commented Jan 25, 2019

What's happening with Flow is so regretful. It is so hard to evangelize Flow in commercial environments. Despite all its benefits, how can you promote something that still partially broken on some platforms (hello Windows) and broken completely for almost half a year in Windows version of the VS Code?

We all understand that Facebook and Flow teams own nothing to anyone. Still, it is sad to see how extremely bad tool taking on the market. Let's be honest — it will be nearly impossible to battle TypeScript those days without some good efforts.

giphy

But I'm still with you, guys. The Force should be on your side.

@ArmorDarks

This comment has been minimized.

Copy link

@ArmorDarks ArmorDarks commented Jan 25, 2019

To be more specific, at least a few things should be done to start moving:

  1. Roadmap per year with generic milestones, to see where it's heading. Some form of sprints (probably, per month or per quarter) should be used to set specific short-term goals.

    Reflecting on the past experience, I can surely say that without it development will continue to be stale and chaotic. The community will gladly help to shape it to ensure that only needed features are included first.

    Having the plan means we'll know what to expect and when it will be ready for real use. That will give the community more encouragement to actually talk about Flow.

  2. Fix Flow and plugins on all major platforms.

    Seriously, it's about time. It should at least work without some major bugs. None tools can be viable for commercial use without it. And without commercial use, any tool will remain the toy for geeks.

  3. Provide a better and extendable way to write libraries definitions, which also could be stored within library repository and automatically used, and not within flow-typed repository. Provide a better way to write types for specific versions with overrides, which should fix current pain of the Flow — constant depreciations and breaking changes, which forcing people to keep their own types within flow-typed directory.

    flow-typed is a mess. Storing types within libraries will by the way to fix the issue with versioning of types.

    The way to specify types for libraries in a graceful way is extremely important, it will make Flow coverage more common thing. After all, right now coverage of TS is one of the main reasons why it became so hyped.

That should make Flow at least a viable option.

@psirenny

This comment has been minimized.

Copy link

@psirenny psirenny commented Jan 25, 2019

I think one could make a strong case for decentralizing flow typedefs. There's a tradeoff to be made between typedef quality (a centrally maintained flow-typed repository) vs. typedef availability (types maintained by numerous 3rd parties). However in my opinion, the community has already voted in favor of availability by adopting typescript.

The flow-typed tool could be made to facilitate importing typedefs from other repositories. Authors would be incentivized to create typedefs because they would receive the lion share of the praise for doing so. Likewise, they would not be disincentivized from creating typedefs because they would not have to wait for Github gatekeepers to review and possibly reject their pull request.

@zeorin

This comment has been minimized.

Copy link

@zeorin zeorin commented Jan 25, 2019

@ArmorDarks flow-typed is getting better: flow-typed/flow-typed#3083

But it feels like that project gets little to no support from FB. The community has to keep even Redux's types up-to-date themselves.

@pascalduez

This comment has been minimized.

Copy link
Contributor

@pascalduez pascalduez commented Jan 26, 2019

One way to help library authors deliver definitions with there packages could be to revive flow-gen-type or similar mechanism and make it a first class citizen.
Right now the available solutions/hacks are all clumsy and it's one of the major criticism against flow.
Manually creating the def or flow-copy-source or publish the whole sources, etc...

Combined with flow-typed upcoming plans we could really make a difference here.

@TrySound

This comment has been minimized.

Copy link
Collaborator

@TrySound TrySound commented Jan 26, 2019

@pascalduez flow-gen-type replacement is coming soon. They already work on it for a while.

@ArmorDarks

This comment has been minimized.

Copy link

@ArmorDarks ArmorDarks commented Jan 26, 2019

I've probably been too specific about what to do with flow-typed and accidentally started an offtopic here. Specifics of that solution better to discuss in dedicated issue.

I rather wanted to highlight that current way to publish library typings is so painful that only because of that many developers even didn't consider adding Flow types.

Just imagine all the steps maintainers have to go those days to publish any library and throw on top of that the need to publish types to the 3rd-party repository and wait for them to be approved. Ignoring the fact that it is tons of hassle by its own to keep in sync something you don't own directly, what should happen with the release in that time? Be released without types? Put on hold release only because of the PR?

Since it makes Flow grow problematic, it is one of the major issues which should be addressed. That was the point.

@villesau

This comment has been minimized.

Copy link
Collaborator

@villesau villesau commented Jan 26, 2019

@ArmorDarks and others, if you have ideas on how to make flow-typed better, feel free to open issues in the repo! We are happy to hear and consider any improvement ideas. Currently we are researching the option to publish libdefs in NPM. Also note that any support from community is highly appreciated since maintainers have very limited amount of time to put effort on the project.

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 28, 2019

Thanks everyone for all the input. You've all made some good points. Regarding flow-typed, I agree that discussions about specifics should be taken elsewhere. The Flow team is very grateful to the folks maintaining it. We are planning to provide a replacement for gen-flow-files that actually works (it was experimental and basically broken from the beginning). We have the core logic done, but we still need to package it all up into a useful command. This should make it much easier to contribute to flow-typed.

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Jan 28, 2019

@vjpr

This comment has been minimized.

Copy link

@vjpr vjpr commented Feb 1, 2019

@nmote

Just want to cross-post my comment here: #6833 (comment)

In summary: there are many issues around monorepos and node_modules that prevent people from being able to use Flow (without tons of brittle hacks), or force Flow to read all the files in your node_modules directory.

I have moved to TypeScript this week because I simply could not get Flow to work with my codebase. I tried for like 2 years to get the right config but just couldn't get it to work. The changes needed are tiny config options which lots of community support that were ignored by the Flow team.

Please fix the basics first!

@nmote

This comment has been minimized.

Copy link
Contributor

@nmote nmote commented Feb 1, 2019

We're considering our options around node_modules. We don't have anything to announce at the moment but it's an issue I would like to tackle. Just a few minutes before you posted this I started a discussion on our new Discord server on how to better handle node_modules. Feel free to join in if you would like to provide your input. I'll address your other comments on that issue.

@Bessonov

This comment was marked as disruptive content.

Copy link

@Bessonov Bessonov commented Mar 21, 2019

It's not my beer, but I think it's better to put resources in other projects like fixing react-native (they really need help, very much help) or shiny new yarn2. I'm ts user from 1.5/1.6. I've never use flow, because from my point of view idea/concept of ts and implementation were superior from beginning. More and more projects switch from js to ts, which is great.

Down votes to get more self-actualisation are welcome 👍

@TrySound TrySound referenced this issue Apr 11, 2019
@rostislav-simonik

This comment has been minimized.

Copy link
Contributor

@rostislav-simonik rostislav-simonik commented Apr 21, 2019

It's not about whether typescript is better or flow is better. For somebody typescripts fits better and for other person flow does. For my purposes flow suits me better because it gives me more freedom, it doesn't contain some architecture limitations like other competitive language type systems do.

There has been some unfortunate events like archiving nuclide, because default type system in IDE does the conversion. Yes there is vscode alternative but it defaults to typescript, and require some setup. Also author of extension migrated to typescript ;).

So what we need to do is better support for flow. We can't to expect that facebook team does everything. What i read i assume they prioritise they internal projects.

If we want to spread flow more, then I think:

  1. we need also to engage more not so much experienced people to process to write typings for external dependencies. Currently it's so much complicated (flow-typed), yes it is. I'd expect that people can easily contribute, as wiki does. And if they create wrong update, so somebody immediately fix that. (No moderated PR, No Tests). I'm waiting for upcoming flow release and with hope that I won't find any obstacle i'll write POC (meeting ideas in v3 proposal of flow-typed) how to create external typing just by npm packages, and .flowconfig. No flow-typed tool needed.It will have some gray areas, but will sufficient until flow-typed v3 will be introduced.
  2. we need to reuse typescript definitions somehow.

So instead of complaining let's do something.

@goodmind

This comment has been minimized.

Copy link
Collaborator

@goodmind goodmind commented Apr 21, 2019

@rostislav-simonik, you can generate Flow from TypeScript with flowgen, but it is not perfect, I already converted all of DefinitelyTyped https://github.com/goodmind/FlowDefinitelyTyped/tree/master/flow-types/types, but there is still many errors in automatic conversion

I believe @nmote explores .js.flow for flow-typed in npm instead of libdefs

@debel27

This comment has been minimized.

Copy link

@debel27 debel27 commented Apr 21, 2019

I'm waiting for upcoming flow release and with hope that I won't find any obstacle i'll write POC (meeting ideas in v3 proposal of flow-typed) how to create external typing just by npm packages, and .flowconfig. No flow-typed tool needed.It will have some gray areas, but will sufficient until flow-typed v3 will be introduced.

Sounds great. Could you provide a link to this POC in this topic when it's ready ?

I believe @nmote explores .js.flow for flow-typed in npm instead of libdefs

This is by far my favorite method, though it might be complicated to setup in non-flow projects.
This would require no external install whatsoever and would work out of the box.

@rostislav-simonik

This comment has been minimized.

Copy link
Contributor

@rostislav-simonik rostislav-simonik commented Apr 21, 2019

@rostislav-simonik, you can generate Flow from TypeScript with flowgen, but it is not perfect, I already converted all of DefinitelyTyped https://github.com/goodmind/FlowDefinitelyTyped/tree/master/flow-types/types, but there is still many errors in automatic conversion

I believe @nmote explores .js.flow for flow-typed in npm instead of libdefs

Great. Could you @goodmind please elaborate more (probably would be better to start, find another issue, due it's not related to this topic). My question is what kind of errors you are referencing to. Thanks.

@rostislav-simonik

This comment has been minimized.

Copy link
Contributor

@rostislav-simonik rostislav-simonik commented Apr 21, 2019

Sounds great. Could you provide a link to this POC in this topic when it's ready ?

@debel27 np, I'll create issue on flow-typed and will comment and reference it from here then.

@goodmind

This comment has been minimized.

Copy link
Collaborator

@goodmind goodmind commented Apr 21, 2019

@rostislav-simonik maybe you can join Flow Discord, I don't think it is suited for issues

@villesau

This comment has been minimized.

Copy link
Collaborator

@villesau villesau commented Apr 25, 2019

@rostislav-simonik there is some work to push libdefs to NPM: flow-typed/flow-typed#3083 Unfortunately progressing very slowly due to other priorities.

@rostislav-simonik

This comment has been minimized.

Copy link
Contributor

@rostislav-simonik rostislav-simonik commented Apr 26, 2019

@villesau Thanks for comment, yes I know. I've read your issue before. I wanna to try poc how to do it manually but will use your proposal so packages will look like flow-typed created them, so we won't be blocked until v3 of flow-typed will be finished.

I understand i'm also occupied by other priorities, so maybe incremental approach would be better.

@orta

This comment has been minimized.

Copy link

@orta orta commented Apr 26, 2019

While we're chatting about flowgen I wonder if it's worth migrating it into the flowtype (or flow-typed) org? /cc @joarwilk

@villesau

This comment has been minimized.

Copy link
Collaborator

@villesau villesau commented Apr 26, 2019

@rostislav-simonik nice to see that there is enthusiasm to improve the situation with libdefs! I'm curious to see how the POC turns out. I like the approach you are proposing, but as with wikis, there are risks which i'm uncertain about. That said, people who review the libdefs are by no means better in their job than anyone else - just a bit more practiced about libdefs in general. No-one knows the nuances of all the different libdefs so it's nearly impossible to guarantee the uniform quality of them.
AFAIK TS does it in a way that it pings previous contributors first, and if no reviewer appear in 8 days or so, someone from the core team reviews. But other than that definitely-typed relies on pretty similar way than flow-typed. In our case we don't have such bot, but it's always someone from core team
who reviews unless someone else have already reviewed it carefully.

@orta I think flowtype would be perfect home for flowgen if you are considering moving. But flow-typed has a benefit that no need to sign FB CLA or go trough FB process when adding or removing maintainers. This was the reason flow-typed was moved into it's own organisation from flowtype back in the days. (cc. @GAntoine )

@kevinbarabash

This comment has been minimized.

Copy link

@kevinbarabash kevinbarabash commented Aug 8, 2019

It feels like flow's been steadily getting better. There were a couple of issues that were bugging me a couple of months ago (inference of basic things like Array.prototype.map and variance of literal assignments) that been resolved.

One thing that always catches me off-guard is how many stale PRs there are in this repo. I know there are probably bigger fish to fry, but closing old PRs that are never going to get merged wouldn't take that long and would signal that someone's looking at things.

Also, I think the CONTRIBUTING.md could be expanded to talk about what kinds of changes the flow team is looking for, coding standards, maybe a high-level overview of how flow's type-checker works.

@goodmind

This comment has been minimized.

Copy link
Collaborator

@goodmind goodmind commented Aug 8, 2019

@kevinbarabash there was ton of PRs closed, if you filter by is:closed -label:Merged, but.mostly because they're old, not because there isn't value in merging them

You can find high-level overview of typechecker in wiki

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.