4 ms·

I prefer Flowtype, but I definitely agree that TypeScript seems to be winning on the popularity front. One of the big problems is that flow has far fewer defin

I prefer Flowtype, but I definitely agree that TypeScript seems to be winning on the popularity front. One of the big problems is that flow has far fewer definition files available. Most projects don't want to support two separate type specs. Even if it didn't provide 100% compatibility, having something take you 90% of the way there would be a big improvement. But I'm still betting on flow. I like that it's supported by babel and it generally seems to be better at helping you catch bugs. @thejameskyle recently tweeted [0] a short snippet showing a great example showcasing flow. [0] https://twitter.com/thejameskyle/status/868148120504356864 https://twitter.com/thejameskyle/status/868148120504356864

AgentME 9y ago
Does Typescript still require you to have definitions for every library in order to use the library? One thing I love about Flow is that it doesn't have that requirement. You can start using a new library, and later on if you find that type safety in that library's exports would be useful, then you can look for or write definitions then. You're not blocked from adopting the library. I find for many of my dependencies that I use in a few spots it's not really important for me to have definitions for.
- typebore 9y ago
  technically you do need to define at the top level, but no, not in a practical sense: declare var $: any; $( "element" ).compiler.leaves.you.alone
- jsight 9y ago
  I don't think that Typescript ever did require that? AFAIK, it has always been possible to just declare the variable as "any" type and use it as if it were untyped.
  - neilsimp1 9y ago
    Can confirm. This has been my experience.
  - AgentME 9y ago
    I thought I remembered using require statements and getting errors from the typescript compiler that it couldn't find the (typescript definitions for the) file.
- boubiyeah 9y ago
  You can always add a quick and dirty definition like: declare module 'themodule' { var mock: any; export default mock; } But unless the lib doesn't propagate through your code at all, it pays of to give it proper typings.
  - mattmanser 9y ago
    In the rare cases we find a library that doesn't have a typescript definition, we just do: declare var Thing : any; In a global definition file. Pro tip. We've got a lot of mixed js and ts at the moment and when you're really lazy you can take advantage of how every object is a dictionary in js and just do something like `window["notification"]` instead of window.notification, which resolves to an 'any' type in ts. Obviously you should try and minimise that usage, but it's a useful trick to know.
    - mercer 9y ago
      Is that still the case with the recent update to TypeScript now that it also typechecks object['prop']?
orif 9y ago
TypeScript would complain about that snippet too. function getOptions() { return { num: 42, str: "val" }; } var __options__ = getOptions(); type Options = typeof __options__; var options: Options = { ^^^^ Type is not assignable num: "hi", str: 42 };
- silviogutierrez 9y ago
  I love TS and cannot speak enough good things about it. But in your TS example, the code would execute. Not in the Flow example, where it's just an annotation. There are hacks and other approaches, documented here: https://github.com/Microsoft/TypeScript/issues/6606 https://github.com/Microsoft/TypeScript/issues/6606
  - Arnavion 9y ago
    >But in your TS example, the code would execute. Incorrect. It's a type alias so it uses "type typeof" not "value typeof". It doesn't have the problem that the issue you linked to is about. https://www.typescriptlang.org/play/#src=function%20getOptions()%20%7B%20return%20%7B%20num%3A%2042%2C%20str%3A%20%22val%22%20%7D%3B%20%7D%0D%0Avar%20__options__%20%3D%20getOptions()%3B%0D%0Atype%20Options%20%3D%20typeof%20__options__%3B%0D%0Avar%20options%3A%20Options%20%3D%20%7B%0D%0A%20%20%20%20num%3A%20%22hi%22%2C%0D%0A%20%20%20%20str%3A%2042%0D%0A%7D%3B https://www.typescriptlang.org/play/#src=function%20getOptio... Observe the JS output contains no `typeof` and that the type `Options` is considered to be the same as `{ num: number, str: string }` if you hover over it.
    - silviogutierrez 9y ago
      I don't understand. In your transpiled code, getOptions is clearly being called in JS. In flow, getOptions() wouldn't be in the transpiled code at all. Imagine the body of getOptions as an extremely expensive computation. Some prime calculation. But you only want its return type. In flow comments, you can get it. In the approach of your snippet, you could get it, but it will execute the full function with the full price.

AgentME 9y ago

Does Typescript still require you to have definitions for every library in order to use the library? One thing I love about Flow is that it doesn't have that requirement. You can start using a new library, and later on if you find that type safety in that library's exports would be useful, then you can look for or write definitions then. You're not blocked from adopting the library. I find for many of my dependencies that I use in a few spots it's not really important for me to have definitions for.

typebore 9y ago
technically you do need to define at the top level, but no, not in a practical sense: declare var $: any; $( "element" ).compiler.leaves.you.alone
jsight 9y ago
I don't think that Typescript ever did require that? AFAIK, it has always been possible to just declare the variable as "any" type and use it as if it were untyped.
- neilsimp1 9y ago
  Can confirm. This has been my experience.
- AgentME 9y ago
  I thought I remembered using require statements and getting errors from the typescript compiler that it couldn't find the (typescript definitions for the) file.
boubiyeah 9y ago
You can always add a quick and dirty definition like: declare module 'themodule' { var mock: any; export default mock; } But unless the lib doesn't propagate through your code at all, it pays of to give it proper typings.
- mattmanser 9y ago
  In the rare cases we find a library that doesn't have a typescript definition, we just do: declare var Thing : any; In a global definition file. Pro tip. We've got a lot of mixed js and ts at the moment and when you're really lazy you can take advantage of how every object is a dictionary in js and just do something like `window["notification"]` instead of window.notification, which resolves to an 'any' type in ts. Obviously you should try and minimise that usage, but it's a useful trick to know.
  - mercer 9y ago
    Is that still the case with the recent update to TypeScript now that it also typechecks object['prop']?

orif 9y ago

TypeScript would complain about that snippet too. function getOptions() { return { num: 42, str: "val" }; } var __options__ = getOptions(); type Options = typeof __options__; var options: Options = { ^^^^ Type is not assignable num: "hi", str: 42 };

silviogutierrez 9y ago
I love TS and cannot speak enough good things about it. But in your TS example, the code would execute. Not in the Flow example, where it's just an annotation. There are hacks and other approaches, documented here: https://github.com/Microsoft/TypeScript/issues/6606 https://github.com/Microsoft/TypeScript/issues/6606
- Arnavion 9y ago
  >But in your TS example, the code would execute. Incorrect. It's a type alias so it uses "type typeof" not "value typeof". It doesn't have the problem that the issue you linked to is about. https://www.typescriptlang.org/play/#src=function%20getOptions()%20%7B%20return%20%7B%20num%3A%2042%2C%20str%3A%20%22val%22%20%7D%3B%20%7D%0D%0Avar%20__options__%20%3D%20getOptions()%3B%0D%0Atype%20Options%20%3D%20typeof%20__options__%3B%0D%0Avar%20options%3A%20Options%20%3D%20%7B%0D%0A%20%20%20%20num%3A%20%22hi%22%2C%0D%0A%20%20%20%20str%3A%2042%0D%0A%7D%3B https://www.typescriptlang.org/play/#src=function%20getOptio... Observe the JS output contains no `typeof` and that the type `Options` is considered to be the same as `{ num: number, str: string }` if you hover over it.
  - silviogutierrez 9y ago
    I don't understand. In your transpiled code, getOptions is clearly being called in JS. In flow, getOptions() wouldn't be in the transpiled code at all. Imagine the body of getOptions as an extremely expensive computation. Some prime calculation. But you only want its return type. In flow comments, you can get it. In the approach of your snippet, you could get it, but it will execute the full function with the full price.