flow-remove-types

🚿 Removes Flow type annotations from JavaScript files with speed and simplicity.

Web Development

Explore on GitHub Read Hacker News discussions

2Distinct people

2Mentions

0Explicit recommenders

464GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

🚿 Removes Flow type annotations from JavaScript files with speed and simplicity.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month2 dated mentions

Observed mentions: 2017-09-13 06:54:21 UTC to 2019-01-24 21:13:06 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Sep 2017	2017-09-01 00:00:00 UTC	2017-10-01 00:00:00 UTC	1	1
Oct 2017	2017-10-01 00:00:00 UTC	2017-11-01 00:00:00 UTC	0	0
Nov 2017	2017-11-01 00:00:00 UTC	2017-12-01 00:00:00 UTC	0	0
Dec 2017	2017-12-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
Jan 2018	2018-01-01 00:00:00 UTC	2018-02-01 00:00:00 UTC	0	0
Feb 2018	2018-02-01 00:00:00 UTC	2018-03-01 00:00:00 UTC	0	0
Mar 2018	2018-03-01 00:00:00 UTC	2018-04-01 00:00:00 UTC	0	0
Apr 2018	2018-04-01 00:00:00 UTC	2018-05-01 00:00:00 UTC	0	0
May 2018	2018-05-01 00:00:00 UTC	2018-06-01 00:00:00 UTC	0	0
Jun 2018	2018-06-01 00:00:00 UTC	2018-07-01 00:00:00 UTC	0	0
Jul 2018	2018-07-01 00:00:00 UTC	2018-08-01 00:00:00 UTC	0	0
Aug 2018	2018-08-01 00:00:00 UTC	2018-09-01 00:00:00 UTC	0	0
Sep 2018	2018-09-01 00:00:00 UTC	2018-10-01 00:00:00 UTC	0	0
Oct 2018	2018-10-01 00:00:00 UTC	2018-11-01 00:00:00 UTC	0	0
Nov 2018	2018-11-01 00:00:00 UTC	2018-12-01 00:00:00 UTC	0	0
Dec 2018	2018-12-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
Jan 2019	2019-01-01 00:00:00 UTC	2019-02-01 00:00:00 UTC	1	1

What Hacker News says

2 sources

dntrkv·Jan 24, 2019

There is no difference if you limit the use of the tool to not use these features. In my eyes, it's a philosophical difference between the two, Flow can be more easily integrated into an existing codebase by just adding //@flow at the top the file and has no features which can affect runtime code. Whereas TypeScript tries to be a different language altogether that uses a new file extension, adds new features, and has its own compiler. When you can implement a tool like this using TS, let me know https://github.com/flowtype/flow-remove-types

In Yarn's Future – v2 and beyond

lewisl9029·Sep 13, 2017

> Given that TypeScript is a transpiler along with a static type-checker, it's not always easy to tell which features are going to have build-time vs run-time effects (e.g. private properties, property decorators) This is a huge part of why I tend to prefer Flow for my projects these days as well. I really value the fact that Flow is just a thin layer of static type annotations you place on top of your spec-compliant JavaScript, and none of its features have any chance of introducing unexpected runtime behavior. Also, I'd like to add that using Flow with Babel transpilation targeting a ES20xx preset largely guarantees that the source code you're writing is valid spec-compliant JavaScript that can run without transpilation one day (requiring only a dead-simple type-stripping transform using something like https://www.npmjs.com/package/babe

Read the rest

l-plugin-transform-flow-st... or https://github.com/flowtype/flow-remove-types), and I've had great success with simply dropping all/parts of the transpilation step as the features I use start to become supported in node/browsers/react-native/electron/runtime-polyfills/etc for apps where I don't plan on supporting browsers more than a few versions behind latest, which has been an absolute godsend for debugging in both development and production. I highly encourage people to try it out on a project where they can afford to do the same (i.e. for packaged projects where you have control over the runtime environment like Electron or React Native, or for web projects where most of your users happen to be also web developers). It's really been a breath of fresh air after dealing with all sorts of subtle transpilation induced bugs/edge-cases. To be clear, I'm not trying to bash TypeScript, because it's an awesome project, with top-class tooling that has attracted an amazing community around it. I just wanted to remind all the people mindlessly shouting "TypeScript has won" into their own silos, that Flow is also a great type system, that just happens to be designed with a fundamentally different set of trade-offs in mind. That alone doesn't make either system better or worse than the other, but it does mean there are use cases where Flow can excel over TypeScript and vice versa, and that you should carefully consider your project's needs and what characteristics you value in a type system before simply cargo-culting one or the other.

In Flow and TypeScript