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

Replace Flow with Typescript. #138

Closed
bertrandmc opened this issue Oct 1, 2020 · 0 comments
Closed

Replace Flow with Typescript. #138

bertrandmc opened this issue Oct 1, 2020 · 0 comments

Comments

@bertrandmc
Copy link
Contributor

Replace Flow with Typescript.

Motivation

Because during the last year things have changed considerably in the JS ecosystem and also due to some limitations we have just encountered with Flow, I want to propose we migrate from Flow vs Typescript. I believe making this change will benefit the project short and long term and below are the main reasons for this:

  1. Due to limitation with flow (incompatibility with Private Class Methods and Properties) we cannot add Prettier to help with code formatting and stronger linting. The same limitation blocks us from properly type check all workspaces' files because we are already using @babel/plugin-proposal-private-methods and @babel/plugin-proposal-class-properties to support these features (which are already in EC39 stage 3)

  2. There is an open issue with Flow requesting this feature since 2018 which has never received any attention from a team member.

  3. Flow implements it's own private class methods using munge_underscores which goes away from Javascript specification and adds complexity to the stack (developers have already chosen the proposed EC39 hash # implementation).

  4. Flow adoption is decreasing and even internal Facebook teams are moving from Flow to Typescript. See Jest and Yarn.

  5. Typescript's huge adoption makes the ecosystem more supportive with more tools available. See both Flow and Typescript trends here.

  6. Because most Javascript ecosystem libraries are written in Typescript the application can benefit considerably from it, with Flow we have to manually create these types or use what is available in flow-typed, which is a fraction of the Javascript ecosystem, some libraries do add helpers to support flow, for example date-fns, which is written is Typescript but at the moment is doing some effort to expose flow types, such support can be eventually dropped considering the trend adoption with flow, which will bring difficulties to the long-term maintenance of the application.

  7. If the industry is strongly pointing towards Typescript, having flow could make onboarding of team members and open source collaborators harder because coder's tend to look forward to work with widely adopted technologies.

Why now is the ideal moment to do this?

  1. At the moment we only have 15 files using flow types and migrating this wouldn't take too long.
  2. The adoption of Typescript can be gradual as we can support a mix of JavaScript and TypeScrip files.
  3. We'd be able to use prettier and implement strong linting and code formatting rules.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants