13 ms·

Migrate Jest to TypeScript

261 points by whatever_dude 8y ago

GutenYe 8y ago
But both Flow and Jest are both developed by the Facebook team. First of all, like the author, I didn't say Flow is bad than TypeScript. Secondly, I moved from Flow to TypeScript last year. Anyway, this going to have a huge impact on Flow ecosystem.
- akmittal 8y ago
  From last few months react community is embracing Typescript. create-react-app added support for typescript.
- _the_inflator 8y ago
  FB devs show that there are no dogmas, only different solutions to different problems. Flow has its merits and was a good start as an experiment back then.
- draw_down 8y ago
  There is no “the Facebook team”
Rapzid 8y ago
As a TypeScript Jest consumer can't complain, though @types/jest is pretty good. I would be much more excited if they opened up Jest to be more "programmable" though. Dynamically creating tests and etc(before you ask, I was looking into wrapping an existing bash test framework in Jest). Perhaps the move to TS will make more of the internal interfaces feel public?
knocte 8y ago
I much prefer TypeScript than JavaScript, but TS can still allow shitty code, such as: * Using the type 'any'. * Using the immediate value `undefined` (JS is mental in the fact that it has two kinds of null... and with TS there's really no excuse for using this one, however TS compiler doesn't complain). * Using very ugly, or very easy to be misleading, typeguards (granted, TS doesn't have decent typeguards, see https://github.com/Microsoft/TypeScript/issues/28337 https://github.com/Microsoft/TypeScript/issues/28337 ...). For these reasons, I applaud JS people moving to TS. But I will not recommend any other people (non-JS) to use TS at all.
- aphextron 8y ago
  >* Using the type 'any'. This is easily enforced in your tsconfig.json
  - knocte 8y ago
    Yeah but a decent tsc configuration is not default, so many people are still writing shitty typescript.
    - 59nadir 8y ago
      `"strict": true` is turned on by default when you run `tsc --init` and is recommended in every talk by everyone, including the TypeScript team... So I'm afraid the defaults are indeed sane and exactly what you want. I'm not sure much of what you've said in these threads really gels with reality so far. For anyone confused: `"strict": true` in `tsconfig.json` just blanket enables all type checks, including future ones. You can then opt out of specific ones of your choosing if there's too much pain caused by the original authors, but none of those things are added by default. The TS team wants you to leave strict mode on.
      - Rapzid 8y ago
        To add to this, flow control analysis requires certain stict features. To be a bit obtuse; you want flow control analysis ergo you want strict :)
    - jrockway 8y ago
      You are grasping at straws at this point. TypeScript is not the end all and be all of programming languages. It tweaks Javascript to be a little bit more sane, that's all. The kinds of people that seek out this sort of thing probably know whether or not to enable "any", and did so for their configurations. Either decision paves the way towards a cleaner future; those that started from zero and had "any" disabled on day 1, or those that are cleaning up a large codebase and are slowly making progress cleaning it up. TypeScript lets you be either person and lets you make your own decision. It is clear to someone with even cursory knowledge of Javascript and TypeScript what options are available in this regard. Whatever the default is, people can probably make the right decision for their application. It's not hard and it's not hidden.
dcosson 8y ago
Interesting move. If major projects within Facebook are migrating away it seems pretty likely that Flow is on the way out. Which I think would be a good thing, it seems like a lot of projects and libraries haven't fully embraced either because it's unclear which to choose. In this case I don't think the "competition makes them better" aspect outweighs the downsides of having a fragmented community.
- brylie 8y ago
  That x10 for the frontend component ecosystem.
- hitekker 8y ago
  IIRC, the writing was on the wall for flow these last two years. Aside from a few core users, it was never really as popular or as responsive as TypeScript was. More a fad than the future, I suppose. But at least flow brought some valid ideas to the table, e.g., strictness.
  - vanderZwan 8y ago
    > More a fad than the future, I suppose I think that could be seen as a bit harsh, especially in light of the follow-up sentence. What Flow added to the JS ecosystem is probably the future, it's just that the implementation of that future seems to be TypeScript.
    - hitekker 8y ago
      I recall the Nomad being described as the future too, and the iPod described as some boring "friendly" implementation of that future.
- jchw 8y ago
  There was a time when TypeScript was woefully incomplete when compared with FlowType. When I first had to choose between them, the thing that sold FlowType to me was how it handled null checking, but I was also impressed with the rich type system with advanced type inference. Then of course, TypeScript greatly improved and added many of those features. The Flow type inference engine is probably still more advanced, but TypeScript does good enough, and has good developer ergonomics all across the board. Hopefully Flow improved since I last used it but if not it regularly ate tons of memory, was difficult to configure, and had poor IDE integration. So in the modern TypeScript world it's hard to choose Flow despite it's potential advantages, imo.
yakshaving_jgt 8y ago
I’d say “why not just use Elm” (or some other language designed for types), but every time I do that it seems to summon some weirdo who keeps harassing me with “hurrrr durrr there’s no evidence that types help with anything!!”
- jeremy_wiebe 8y ago
  I think this was addressed directly when Reason was mentioned as a better option... > @orta already answered here, but the tl;dr (at least to me) is that the point here is to make the code base more approachable to to new (and old) contributors who are consumers of Jest. The vast majority of them are JavaScript developers, not OCaml developers.
- StreamBright 8y ago
  You put out your opinion, another user puts out his opinion. If you think different opinions are harassment what are you doing on HN?
  - yakshaving_jgt 8y ago
    Oh hey! It's you again! (not the original guy I had in mind though, and it isn't just on HN)
- ascorbic 8y ago
  It's a large codebase that already uses Flow types, which has almost identical syntax to TypeScript, and its users are almost all JS or TS developers.
- matthewmacleod 8y ago
  “… so I’ll low-key passive-aggressively do it while pretending to comment”? :) Look, Elm and Typescript are two very different things with different goals. There’s no problem developing a new app in Elm if it suits your use-case, but if you’re doing any number of other things - improving an existing app, writing a server app, working with Javascript developers - Typescript might be a more suitable choice. From my point of view, I was able to slowly convert an existing large web app to Typescript over the course of a few months by rewriting a file whenever I touched it. Now the code is more reliable and easier to work on. That’s a good solution, but not one that would have been feasible with Elm.
knowThySelfx 8y ago
I like plain Javascript more. I guess those who are from Java/C# background would like TS.
- knowThySelfx 8y ago
  Part of the reason is setting up the environment to run all these and the compilation overhead to see the result in browser. I would also like WebAssembly to really take off.
- peteretep 8y ago
  > I guess those who are from Java/C# background would like TS Been using dynamic languages almost entirely for the last 20 years. I love TypeScript. Starting to wish the other languages I worked with had optional types.
  - scrollaway 8y ago
    Good optional types that is. Python, my love of the last 15 years, is finally adopting optional typing but it's an atrociously bad system compared to typescript, to the point that I am seriously wondering if the language will ever have a decent typing system. Having to import basic types, use awkward syntax, etc... Blergh. I really hope we can be more pragmatic and learn from typescript.
    - speedplane 8y ago
      > Python ... I am seriously wondering if the language will ever have a decent typing system. Considering that everyone seems to use six to target both Python 2 and 3, I am seriously wondering if the language will ever advance at all.
      - basil-rash 8y ago
        I don't think we'll get a Python 4 in the foreseeable future ([1] goes into more detail, from a core CPython developer's perspective). But that doesn't mean it can't advance, just that everything will be forwards compatible. Think C and C++, or even ECMAScript, for that matter. [1]: https://opensource.com/life/14/9/why-python-4-wont-be-python-3 https://opensource.com/life/14/9/why-python-4-wont-be-python...
Vinnl 8y ago
The TypeScript team really made the right call by adding support for TypeScript syntax to Babel. Ever since that got merged, the floodgates have opened: more and more projects support TypeScript by default or practically only requiring you to flip a switch, making the cost of adopting it (if you don't need to spend time learning it as well) practically zero. No matter how small the project, if I start a new one today, it will be written in TypeScript. Adoption is now at a point where it is exponential: more projects adopting TypeScript, resulting in more typings being available, resulting in more projects adopting TypeScript. If there's one thing you can focus on to learn as a Javascript developer in the near future, I'm sure it is TypeScript.
- scrollaway 8y ago
  As an uninformed typescript dev, can you explain to me how TS Babel support changed things? I understand its mechanical implications, but I don't see why it would matter for adoption.
  - jypepin 8y ago
    Yesterday's post about migrating to typescript [1] explains it well. tldr: This release meant that adopting TypeScript no longer meant buying into the entire TypeScript ecosystem and that we could keep using Babel to emit JavaScript. More importantly, this meant that we could actually use TypeScript as a type checker, and not so much as a "language" per se. [1] https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
  - Vinnl 8y ago
    For example, it made it much easier for projects like Create React App to add optional support for TypeScript. When they added support, that just involved adding an optional extra step to the compilation process (checking whether you violated the type constraints) to make sure you actually get the benefits of TypeScript. Other than that, though, TypeScript projects using CRA use the exact same infrastructure when they use TypeScript, and the compiled output should be similar. Before, this would have involved replacing Babel with TypeScript for transpiling. This means projects could have slightly different results depending on whether they were using TypeScript or not, increasing the surface area for bugs and adding an extra step to the debugging process.
revskill 8y ago
I don't need types in my project, because my architecture is clean enough, so no need for autocomplete here. More messy typings (maybe useless) hurt my eyes and slow down my VSCode as well. Not mention integrating with current JS ecosystem, import, export problem. FIX YOUR ARCHITECTURE FIRST, TYPINGS doesn't help.
ojosilva 8y ago
This is awesome. Just yesterday I was asking around the TS community what good (opensource) CLI with plugins/extensions were there that were written in TS. I was looking for code I could use as learning and inspiration. I was led to vscode and angular-cli, which are both in github. Funny enough, they are also mentioned in this PR's comments. Jest, once/if migrated will be another great addition. Hopefully that will happen soon. The community would really profit from great inspirational codebases (CLIs in my case) written in Typescript.
- Rapzid 8y ago
  Vscode project is a beast with some pretty unintuitive module boundriea due to their platform separation and not bothering to export anything separately (like their IPC system) Check out the CLI for TypeORM. It uses yargs which has pretty good types, and I have used it successfully a couple places now (internally). No plugins or extension examplea though last I looked :(
k__ 8y ago
I don't understand. Why not Reason?
- orta 8y ago
  This was discussed in the issue
- alangpierce 8y ago
  In addition to the "more approachable to contributors" answer, Flow and TypeScript are easy to port between, since they're both light extensions to JS and have almost the same syntax. I've done a Flow to TS port a few times and almost all of the code stays the same, it's just accounting for little differences in the type system details. Switching to a completely different programming language is much more work and much riskier.
jamesisaac 8y ago
Something which I think could be helpful for the overall ecosystem, and allow both type systems to coexist and thrive, would be more attention put into tools which transpile code and type definitions between the two languages. The two most popular projects that I could find[1][2] are unfortunately incomplete and have not received any real updates in months. [1] https://github.com/joarwilk/flowgen https://github.com/joarwilk/flowgen [2] https://github.com/bcherny/flow-to-typescript https://github.com/bcherny/flow-to-typescript
Dirlewanger 8y ago
So how long until the best parts of TypeScript are subsumed into JavaScript, and TypeScript is discarded like CoffeeScript?
- jeremy_wiebe 8y ago
  That would be a good day for everyone, but I don’t see that happening any time soon. TypeScriot has a lot of features and the time to move those through standardization and then runtime (and browser) implementation is nontrivial. If TS runs stalls and doesn’t innovate it _could_ happen, but like I say, subsiding all of those features into the base language would be a win for everyone.
- alangpierce 8y ago
  CoffeeScript and TypeScript are different enough that I don't think TypeScript could possibly have the same fate. CoffeeScript was all about syntax sugar, but 95% of the value of TypeScript is the typechecker that runs in your dev environment (editor, CI, etc) and has no business running in the browser. I sure hope we don't get to a world where every browser needs to implement a standards-compliant typechecker; that would be both architecturally questionable and greatly slow down improvements to the type system. It would be nice if the browser could accept and execute TypeScript code (that is, ignore the type annotations), which would avoid the need for a transpile step, but that's a relatively minor improvement, and would certainly not be a replacement for TypeScript itself.
  - yazaddaruvala 8y ago
    FWIW, “the browser” already type checks Javascript. Where a compiler would throw an exception, the Javascript runtime creates/destroys optimizations. For example, ‘1 + a’ type checks ‘a’ and optimizes the assembly if ‘a’ is a number. As soon as there is some other type represented by ‘a’ the runtime deoptimizes that method. If the runtime could just throw an exception in those situations and keep the typed optimization a lot of our Javascript might run faster.
    - alangpierce 8y ago
sonaltr 8y ago
I like TS. I really do. It makes life nice and easy to catch bugs quite quickly and also makes you think about your code quite a bit more (which I guess makes you a bit slower but it's important enough so it's ok). What is annoying is when you are stuck on something and can't continue because you can't figure out the type of a specific object (and you've disabled any / or you are on the strictest settings). I was recently stuck on ReactJS + Redux + Redux Saga and it took me a while (~ 1 day) to figure it all out (and I'm still not 100% sure if I did it right). It was fine when I disabled the strictest settings for a bit but it's definitely annoying (asking for help in Typescript, React, Redux, Saga and elsewhere didn't really help at all).
- jamesgeck0 8y ago
  > What is annoying is when you are stuck on something and can't continue because you can't figure out the type of a specific object (and you've disabled any / or you are on the strictest settings). In VSCocde I can hover over variable names to display the type of an object in a tooltip. I assume this information is available for other editors as well via the typescript language server.
  - mattferderer 8y ago
    Also in VS Code you can click F12 to go to the definition. When importing something new, I will often do this & then spend time reading through all of their type information. This often makes amazing documentation! When TypeScript first came out, this really helped me learn JavaScript & DOM types that browsers treated differently. It also helped me learn to write cross browser compatible JavaScript without depending on jQuery.
- AriaMinaei 8y ago
  I basically do two things to make sure type checking doesn't slow me down: 1) Use emitOnly: true. This means that if your code has type errors, it still compiles. And you can fix the type error later. 2) Never use any directly. Not all anys are equal. Some are there because you don't have the time to figure out a proper type annotation. Others are there because you can express a proper annotation, but think that it's just not worth the effort. And some anys are there because the type system is not capable of expressing the type you have in mind. What you want to do is to clearly annotate your intention when you're typing something as any. So what I do is to simply disallow directly using any, and instead, use a few global type aliases that better communicate my intention: type $FixMe = any // Fix this type, preferably before accepting the PR type $IntentionalAny = any // This `any` is intentional => never has to be fixed type $Unexpressable = any // TS cannot express the proper type atm I often put these aliases in a defs.d.ts file and use them instead of any.

261 points by whatever_dude 8y ago

But both Flow and Jest are both developed by the Facebook team. First of all, like the author, I didn't say Flow is bad than TypeScript. Secondly, I moved from Flow to TypeScript last year. Anyway, this going to have a huge impact on Flow ecosystem.

akmittal 8y ago
From last few months react community is embracing Typescript. create-react-app added support for typescript.
_the_inflator 8y ago
FB devs show that there are no dogmas, only different solutions to different problems. Flow has its merits and was a good start as an experiment back then.
draw_down 8y ago
There is no “the Facebook team”

Rapzid 8y ago

As a TypeScript Jest consumer can't complain, though @types/jest is pretty good. I would be much more excited if they opened up Jest to be more "programmable" though. Dynamically creating tests and etc(before you ask, I was looking into wrapping an existing bash test framework in Jest). Perhaps the move to TS will make more of the internal interfaces feel public?

knocte 8y ago

I much prefer TypeScript than JavaScript, but TS can still allow shitty code, such as: * Using the type 'any'. * Using the immediate value `undefined` (JS is mental in the fact that it has two kinds of null... and with TS there's really no excuse for using this one, however TS compiler doesn't complain). * Using very ugly, or very easy to be misleading, typeguards (granted, TS doesn't have decent typeguards, see https://github.com/Microsoft/TypeScript/issues/28337 https://github.com/Microsoft/TypeScript/issues/28337 ...). For these reasons, I applaud JS people moving to TS. But I will not recommend any other people (non-JS) to use TS at all.

aphextron 8y ago
>* Using the type 'any'. This is easily enforced in your tsconfig.json
- knocte 8y ago
  Yeah but a decent tsc configuration is not default, so many people are still writing shitty typescript.
  - 59nadir 8y ago
    `"strict": true` is turned on by default when you run `tsc --init` and is recommended in every talk by everyone, including the TypeScript team... So I'm afraid the defaults are indeed sane and exactly what you want. I'm not sure much of what you've said in these threads really gels with reality so far. For anyone confused: `"strict": true` in `tsconfig.json` just blanket enables all type checks, including future ones. You can then opt out of specific ones of your choosing if there's too much pain caused by the original authors, but none of those things are added by default. The TS team wants you to leave strict mode on.
    - Rapzid 8y ago
      To add to this, flow control analysis requires certain stict features. To be a bit obtuse; you want flow control analysis ergo you want strict :)
  - jrockway 8y ago
    You are grasping at straws at this point. TypeScript is not the end all and be all of programming languages. It tweaks Javascript to be a little bit more sane, that's all. The kinds of people that seek out this sort of thing probably know whether or not to enable "any", and did so for their configurations. Either decision paves the way towards a cleaner future; those that started from zero and had "any" disabled on day 1, or those that are cleaning up a large codebase and are slowly making progress cleaning it up. TypeScript lets you be either person and lets you make your own decision. It is clear to someone with even cursory knowledge of Javascript and TypeScript what options are available in this regard. Whatever the default is, people can probably make the right decision for their application. It's not hard and it's not hidden.

dcosson 8y ago

Interesting move. If major projects within Facebook are migrating away it seems pretty likely that Flow is on the way out. Which I think would be a good thing, it seems like a lot of projects and libraries haven't fully embraced either because it's unclear which to choose. In this case I don't think the "competition makes them better" aspect outweighs the downsides of having a fragmented community.

brylie 8y ago
That x10 for the frontend component ecosystem.
hitekker 8y ago
IIRC, the writing was on the wall for flow these last two years. Aside from a few core users, it was never really as popular or as responsive as TypeScript was. More a fad than the future, I suppose. But at least flow brought some valid ideas to the table, e.g., strictness.
- vanderZwan 8y ago
  > More a fad than the future, I suppose I think that could be seen as a bit harsh, especially in light of the follow-up sentence. What Flow added to the JS ecosystem is probably the future, it's just that the implementation of that future seems to be TypeScript.
  - hitekker 8y ago
    I recall the Nomad being described as the future too, and the iPod described as some boring "friendly" implementation of that future.
jchw 8y ago
There was a time when TypeScript was woefully incomplete when compared with FlowType. When I first had to choose between them, the thing that sold FlowType to me was how it handled null checking, but I was also impressed with the rich type system with advanced type inference. Then of course, TypeScript greatly improved and added many of those features. The Flow type inference engine is probably still more advanced, but TypeScript does good enough, and has good developer ergonomics all across the board. Hopefully Flow improved since I last used it but if not it regularly ate tons of memory, was difficult to configure, and had poor IDE integration. So in the modern TypeScript world it's hard to choose Flow despite it's potential advantages, imo.

yakshaving_jgt 8y ago

I’d say “why not just use Elm” (or some other language designed for types), but every time I do that it seems to summon some weirdo who keeps harassing me with “hurrrr durrr there’s no evidence that types help with anything!!”

jeremy_wiebe 8y ago
I think this was addressed directly when Reason was mentioned as a better option... > @orta already answered here, but the tl;dr (at least to me) is that the point here is to make the code base more approachable to to new (and old) contributors who are consumers of Jest. The vast majority of them are JavaScript developers, not OCaml developers.
StreamBright 8y ago
You put out your opinion, another user puts out his opinion. If you think different opinions are harassment what are you doing on HN?
- yakshaving_jgt 8y ago
  Oh hey! It's you again! (not the original guy I had in mind though, and it isn't just on HN)
ascorbic 8y ago
It's a large codebase that already uses Flow types, which has almost identical syntax to TypeScript, and its users are almost all JS or TS developers.
matthewmacleod 8y ago
“… so I’ll low-key passive-aggressively do it while pretending to comment”? :) Look, Elm and Typescript are two very different things with different goals. There’s no problem developing a new app in Elm if it suits your use-case, but if you’re doing any number of other things - improving an existing app, writing a server app, working with Javascript developers - Typescript might be a more suitable choice. From my point of view, I was able to slowly convert an existing large web app to Typescript over the course of a few months by rewriting a file whenever I touched it. Now the code is more reliable and easier to work on. That’s a good solution, but not one that would have been feasible with Elm.

knowThySelfx 8y ago

I like plain Javascript more. I guess those who are from Java/C# background would like TS.

knowThySelfx 8y ago
Part of the reason is setting up the environment to run all these and the compilation overhead to see the result in browser. I would also like WebAssembly to really take off.
peteretep 8y ago
> I guess those who are from Java/C# background would like TS Been using dynamic languages almost entirely for the last 20 years. I love TypeScript. Starting to wish the other languages I worked with had optional types.
- scrollaway 8y ago
  Good optional types that is. Python, my love of the last 15 years, is finally adopting optional typing but it's an atrociously bad system compared to typescript, to the point that I am seriously wondering if the language will ever have a decent typing system. Having to import basic types, use awkward syntax, etc... Blergh. I really hope we can be more pragmatic and learn from typescript.
  - speedplane 8y ago
    > Python ... I am seriously wondering if the language will ever have a decent typing system. Considering that everyone seems to use six to target both Python 2 and 3, I am seriously wondering if the language will ever advance at all.
    - basil-rash 8y ago
      I don't think we'll get a Python 4 in the foreseeable future ([1] goes into more detail, from a core CPython developer's perspective). But that doesn't mean it can't advance, just that everything will be forwards compatible. Think C and C++, or even ECMAScript, for that matter. [1]: https://opensource.com/life/14/9/why-python-4-wont-be-python-3 https://opensource.com/life/14/9/why-python-4-wont-be-python...

Vinnl 8y ago

The TypeScript team really made the right call by adding support for TypeScript syntax to Babel. Ever since that got merged, the floodgates have opened: more and more projects support TypeScript by default or practically only requiring you to flip a switch, making the cost of adopting it (if you don't need to spend time learning it as well) practically zero. No matter how small the project, if I start a new one today, it will be written in TypeScript. Adoption is now at a point where it is exponential: more projects adopting TypeScript, resulting in more typings being available, resulting in more projects adopting TypeScript. If there's one thing you can focus on to learn as a Javascript developer in the near future, I'm sure it is TypeScript.

scrollaway 8y ago
As an uninformed typescript dev, can you explain to me how TS Babel support changed things? I understand its mechanical implications, but I don't see why it would matter for adoption.
- jypepin 8y ago
  Yesterday's post about migrating to typescript [1] explains it well. tldr: This release meant that adopting TypeScript no longer meant buying into the entire TypeScript ecosystem and that we could keep using Babel to emit JavaScript. More importantly, this meant that we could actually use TypeScript as a type checker, and not so much as a "language" per se. [1] https://davidgom.es/porting-30k-lines-of-code-from-flow-to-typescript/ https://davidgom.es/porting-30k-lines-of-code-from-flow-to-t...
- Vinnl 8y ago
  For example, it made it much easier for projects like Create React App to add optional support for TypeScript. When they added support, that just involved adding an optional extra step to the compilation process (checking whether you violated the type constraints) to make sure you actually get the benefits of TypeScript. Other than that, though, TypeScript projects using CRA use the exact same infrastructure when they use TypeScript, and the compiled output should be similar. Before, this would have involved replacing Babel with TypeScript for transpiling. This means projects could have slightly different results depending on whether they were using TypeScript or not, increasing the surface area for bugs and adding an extra step to the debugging process.

revskill 8y ago

I don't need types in my project, because my architecture is clean enough, so no need for autocomplete here. More messy typings (maybe useless) hurt my eyes and slow down my VSCode as well. Not mention integrating with current JS ecosystem, import, export problem. FIX YOUR ARCHITECTURE FIRST, TYPINGS doesn't help.

ojosilva 8y ago

This is awesome. Just yesterday I was asking around the TS community what good (opensource) CLI with plugins/extensions were there that were written in TS. I was looking for code I could use as learning and inspiration. I was led to vscode and angular-cli, which are both in github. Funny enough, they are also mentioned in this PR's comments. Jest, once/if migrated will be another great addition. Hopefully that will happen soon. The community would really profit from great inspirational codebases (CLIs in my case) written in Typescript.

Rapzid 8y ago
Vscode project is a beast with some pretty unintuitive module boundriea due to their platform separation and not bothering to export anything separately (like their IPC system) Check out the CLI for TypeORM. It uses yargs which has pretty good types, and I have used it successfully a couple places now (internally). No plugins or extension examplea though last I looked :(

k__ 8y ago

I don't understand. Why not Reason?

orta 8y ago
This was discussed in the issue
alangpierce 8y ago
In addition to the "more approachable to contributors" answer, Flow and TypeScript are easy to port between, since they're both light extensions to JS and have almost the same syntax. I've done a Flow to TS port a few times and almost all of the code stays the same, it's just accounting for little differences in the type system details. Switching to a completely different programming language is much more work and much riskier.

jamesisaac 8y ago

Something which I think could be helpful for the overall ecosystem, and allow both type systems to coexist and thrive, would be more attention put into tools which transpile code and type definitions between the two languages. The two most popular projects that I could find[1][2] are unfortunately incomplete and have not received any real updates in months. [1] https://github.com/joarwilk/flowgen https://github.com/joarwilk/flowgen [2] https://github.com/bcherny/flow-to-typescript https://github.com/bcherny/flow-to-typescript

Dirlewanger 8y ago

So how long until the best parts of TypeScript are subsumed into JavaScript, and TypeScript is discarded like CoffeeScript?

jeremy_wiebe 8y ago
That would be a good day for everyone, but I don’t see that happening any time soon. TypeScriot has a lot of features and the time to move those through standardization and then runtime (and browser) implementation is nontrivial. If TS runs stalls and doesn’t innovate it _could_ happen, but like I say, subsiding all of those features into the base language would be a win for everyone.
alangpierce 8y ago
CoffeeScript and TypeScript are different enough that I don't think TypeScript could possibly have the same fate. CoffeeScript was all about syntax sugar, but 95% of the value of TypeScript is the typechecker that runs in your dev environment (editor, CI, etc) and has no business running in the browser. I sure hope we don't get to a world where every browser needs to implement a standards-compliant typechecker; that would be both architecturally questionable and greatly slow down improvements to the type system. It would be nice if the browser could accept and execute TypeScript code (that is, ignore the type annotations), which would avoid the need for a transpile step, but that's a relatively minor improvement, and would certainly not be a replacement for TypeScript itself.
- yazaddaruvala 8y ago
  FWIW, “the browser” already type checks Javascript. Where a compiler would throw an exception, the Javascript runtime creates/destroys optimizations. For example, ‘1 + a’ type checks ‘a’ and optimizes the assembly if ‘a’ is a number. As soon as there is some other type represented by ‘a’ the runtime deoptimizes that method. If the runtime could just throw an exception in those situations and keep the typed optimization a lot of our Javascript might run faster.
  - alangpierce 8y ago

sonaltr 8y ago

I like TS. I really do. It makes life nice and easy to catch bugs quite quickly and also makes you think about your code quite a bit more (which I guess makes you a bit slower but it's important enough so it's ok). What is annoying is when you are stuck on something and can't continue because you can't figure out the type of a specific object (and you've disabled any / or you are on the strictest settings). I was recently stuck on ReactJS + Redux + Redux Saga and it took me a while (~ 1 day) to figure it all out (and I'm still not 100% sure if I did it right). It was fine when I disabled the strictest settings for a bit but it's definitely annoying (asking for help in Typescript, React, Redux, Saga and elsewhere didn't really help at all).

jamesgeck0 8y ago
> What is annoying is when you are stuck on something and can't continue because you can't figure out the type of a specific object (and you've disabled any / or you are on the strictest settings). In VSCocde I can hover over variable names to display the type of an object in a tooltip. I assume this information is available for other editors as well via the typescript language server.
- mattferderer 8y ago
  Also in VS Code you can click F12 to go to the definition. When importing something new, I will often do this & then spend time reading through all of their type information. This often makes amazing documentation! When TypeScript first came out, this really helped me learn JavaScript & DOM types that browsers treated differently. It also helped me learn to write cross browser compatible JavaScript without depending on jQuery.
AriaMinaei 8y ago
I basically do two things to make sure type checking doesn't slow me down: 1) Use emitOnly: true. This means that if your code has type errors, it still compiles. And you can fix the type error later. 2) Never use any directly. Not all anys are equal. Some are there because you don't have the time to figure out a proper type annotation. Others are there because you can express a proper annotation, but think that it's just not worth the effort. And some anys are there because the type system is not capable of expressing the type you have in mind. What you want to do is to clearly annotate your intention when you're typing something as any. So what I do is to simply disallow directly using any, and instead, use a few global type aliases that better communicate my intention: type $FixMe = any // Fix this type, preferably before accepting the PR type $IntentionalAny = any // This `any` is intentional => never has to be fixed type $Unexpressable = any // TS cannot express the proper type atm I often put these aliases in a defs.d.ts file and use them instead of any.