You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
There is an open issue with Flow requesting this feature since 2018 which has never received any attention from a team member.
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).
Flow adoption is decreasing and even internal Facebook teams are moving from Flow to Typescript. See Jest and Yarn.
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.
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?
At the moment we only have 15 files using flow types and migrating this wouldn't take too long.
The adoption of Typescript can be gradual as we can support a mix of JavaScript and TypeScrip files.
We'd be able to use prettier and implement strong linting and code formatting rules.
The text was updated successfully, but these errors were encountered:
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:
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)
There is an open issue with Flow requesting this feature since 2018 which has never received any attention from a team member.
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).Flow adoption is decreasing and even internal Facebook teams are moving from Flow to Typescript. See Jest and Yarn.
Typescript's huge adoption makes the ecosystem more supportive with more tools available. See both Flow and Typescript trends here.
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.
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?
The text was updated successfully, but these errors were encountered: