3 ms·

I feel like I can somewhat relate, I've been adding flowtype [0] annotations to my JS code, which is transpiled with babel. However, since I'm using unsupported

I feel like I can somewhat relate, I've been adding flowtype [0] annotations to my JS code, which is transpiled with babel. However, since I'm using unsupported ES2015 features and experimental ES2016+ features, it fails to run over my code (which is completely understandable). The workaround I've found is to use a plugin [1], which converts the type annotations into runtime checks. It's not perfect, but I've found it helps catch some bugs quickly. It's also really helpful for documentation purposes: you know that this function param takes a number param, if you're not passing in a number you've made a mistake. Also, having the inline type is nicer than having it in a jsdoc-style comment above. I think there's diminishing returns as you add more annotations to your code and you make them stricter, but having basic sanity checks has been helpful in catching stupid mistakes quickly. [0] http://flowtype.org/ http://flowtype.org/ [1] https://github.com/codemix/babel-plugin-typecheck https://github.com/codemix/babel-plugin-typecheck

cwyers 11y ago
Why Flow instead of Typescript?
- kcorbitt 11y ago
  Not the OP, but I use flow because (1) it's easy to integrate into an existing project without having to define and rewrite everything with types and (2) I've found myself using other Facebook tools anyway (mostly in the React ecosystem) and Flow tends to be better supported in that world. But I hear the IDE support for TypeScript is first-class, something I haven't found to be the case with Flow, which interests me.
- TheAceOfHearts 11y ago
  Mainly because I was already using babel (which was 6to5 at the time). Typescript didn't support JSX at that time either. I don't know if TypeScript has full ES6 support yet? (And async/await!) Overall babel seems to be moving in a direction which I'd consider really interesting. With babel 6 you'll be able to write a plugin to add runtime checks that aren't limited to module boundaries.
- samwgoldman 11y ago
  One particularly relevant feature of Flow is that it does its type checking in a server. It watches the file system and incrementally rechecks automatically when files change. With this setup, "running" the type checker is actually just querying the server, which returns very quickly.
user1241320 11y ago
Did you take a look at tcomb[0]? [0] https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb
- picardo 11y ago
  Seconded. tcomb is the best dynamic typechecker around.

cwyers 11y ago

Why Flow instead of Typescript?

kcorbitt 11y ago
Not the OP, but I use flow because (1) it's easy to integrate into an existing project without having to define and rewrite everything with types and (2) I've found myself using other Facebook tools anyway (mostly in the React ecosystem) and Flow tends to be better supported in that world. But I hear the IDE support for TypeScript is first-class, something I haven't found to be the case with Flow, which interests me.
TheAceOfHearts 11y ago
Mainly because I was already using babel (which was 6to5 at the time). Typescript didn't support JSX at that time either. I don't know if TypeScript has full ES6 support yet? (And async/await!) Overall babel seems to be moving in a direction which I'd consider really interesting. With babel 6 you'll be able to write a plugin to add runtime checks that aren't limited to module boundaries.
samwgoldman 11y ago
One particularly relevant feature of Flow is that it does its type checking in a server. It watches the file system and incrementally rechecks automatically when files change. With this setup, "running" the type checker is actually just querying the server, which returns very quickly.

user1241320 11y ago

Did you take a look at tcomb[0]? [0] https://github.com/gcanti/tcomb https://github.com/gcanti/tcomb

picardo 11y ago
Seconded. tcomb is the best dynamic typechecker around.