Hyper: Add flow/typescript toolchain/workflow

Created on 24 Feb 2018  Â·  13Comments  Â·  Source: vercel/hyper

We really want to add flow or TypeScript in our project.

First step is to add it to our dev workflow: add dependencies, linter compatibility, automatically run before push...

Please help us to have some benefits of typed system.

good first issue help wanted 💬 Feedback Wanted

Most helpful comment

I'm a user of both TypeScript and Flow. For what it's worth, the xterm.d.ts defs are pretty simple and it would be pretty trivial to write a Flow libdef from it (just taking a glance, I think the file is already 99% compatible with Flow). So if that's the deciding factor, I could submit a PR to flow-typed with a libdef for xterm.

With that said, TypeScript is definitely in the lead when it comes to tooling, community size, and developer support. The Flow team seems to not have too much time to deal with GitHub issues unfortunately, so the support you get from the repo will mainly be from Flow users rather than the Flow team itself:


I haven't been using TypeScript that long, so please correct me if I'm inaccurate about anything, but here is just what I've noticed after having used both:

Pros of Flow:

  • Easier to add in to an existing babel build system (at least until Babel v7 with babel-preset-typescript)
  • More type inference
  • The ability to run flow coverage to see which lines of your code are covered/uncovered and you can also use flow-coverage-report for a general overview
  • Nicer error messages (Flow used to be notorious for it's weird error messages, but as of v0.66, they have been nicer than TypeScript's errors in my projects, even with ts pretty output)

Pros of TypeScript:

  • Much larger community size
  • Way more library definitions
  • The TypeScript team is very active in helping out users and responding to their GitHub issues
  • Works great with VSCode (There is a flow package for VSCode which works well, but the native TypeScript support is on another level)

With all that said, I prefer Flow, but I think TypeScript might be a better choice due to the amount of libdefs/community available. However, I don't really know much about hyper's codebase, so I guess keep that in mind.

Also worth checking out: Why Reddit Chose TypeScript. That article seems to say the same thing – they preferred Flow's type-checking and simpler setup, but they went with TypeScript due to its ecosystem.

All 13 comments

I think it would be better if we used TypeScript since it has more types available and specifically xterm which Hyper is now heavily dependent on is also written in TS.

+1 for TypeScript. TypeScript seems more widely known (I use TypeScript, have not yet used Flow) and seems to have more momentum. It can also pick up jsdoc...

I'm ok with either as long as we have an incremental adoption story. For example, if we can start replacing one .js file at a time with one .ts file, then we can incrementally make lots of little PRs to get to where we want to be.

So far, the appeal of Flow to me has been that incremental adoption strategy. If we can do that with TS, I'm game

No problem to have incremental adoption with TS.
If there is no bonus to use flow (to be compliant with other Zeit's projects, for example), I think that @albinekb has a point: Maybe better to use TS because xterm uses TS.

I let this issue opened to let other people add their inputs. I suggest to definitely choose our type system in 7 days.

Re-adding my thoughts here from Slack. xterm.js was originally a 5k+ line file and separating it out into different files was one of the main reasons to use TS. I incrementally pulled modules out into their own files while converting, you can check what these sort of PRs look like with the linked PRs on https://github.com/xtermjs/xterm.js/issues/335, though it will certainly be easier with Hyper as you already use a newer style of JS.

I'm a user of both TypeScript and Flow. For what it's worth, the xterm.d.ts defs are pretty simple and it would be pretty trivial to write a Flow libdef from it (just taking a glance, I think the file is already 99% compatible with Flow). So if that's the deciding factor, I could submit a PR to flow-typed with a libdef for xterm.

With that said, TypeScript is definitely in the lead when it comes to tooling, community size, and developer support. The Flow team seems to not have too much time to deal with GitHub issues unfortunately, so the support you get from the repo will mainly be from Flow users rather than the Flow team itself:


I haven't been using TypeScript that long, so please correct me if I'm inaccurate about anything, but here is just what I've noticed after having used both:

Pros of Flow:

  • Easier to add in to an existing babel build system (at least until Babel v7 with babel-preset-typescript)
  • More type inference
  • The ability to run flow coverage to see which lines of your code are covered/uncovered and you can also use flow-coverage-report for a general overview
  • Nicer error messages (Flow used to be notorious for it's weird error messages, but as of v0.66, they have been nicer than TypeScript's errors in my projects, even with ts pretty output)

Pros of TypeScript:

  • Much larger community size
  • Way more library definitions
  • The TypeScript team is very active in helping out users and responding to their GitHub issues
  • Works great with VSCode (There is a flow package for VSCode which works well, but the native TypeScript support is on another level)

With all that said, I prefer Flow, but I think TypeScript might be a better choice due to the amount of libdefs/community available. However, I don't really know much about hyper's codebase, so I guess keep that in mind.

Also worth checking out: Why Reddit Chose TypeScript. That article seems to say the same thing – they preferred Flow's type-checking and simpler setup, but they went with TypeScript due to its ecosystem.

@chabou @albinekb any update on this? in case we choose flow or typescript I would like to help in the migration.

As a side note, I submitted a PR to flow-typed for xterm here: https://github.com/flowtype/flow-typed/pull/2017/files

Just so that it isn't the deciding factor. Either way, I'd also be happy to help out if I can in the migration.

As a side note, I submitted a PR to flow-typed for xterm here: https://github.com/flowtype/flow-typed/pull/2017/files

Just so that it isn't the deciding factor.

@saadq this is a little different; the xterm.js API changes pretty much every month and it's source of truth is the TS declaration file shipped with the module. It also appears your editor would lose all the jsdoc info that goes with it when using https://github.com/flowtype/flow-typed/pull/2017/files#diff-160b1966f9630834a6d6fc0154b529d0?

image

Adding the comments to it would be trivial, but yes the fact that the TS typings is provided by xterm itself is definitely a bonus.

Hi, I have opened a pull request #3816 adding TypeScript support.

we're settled for TypeScript now, contributions welcome for porting parts over! :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

silvenon picture silvenon  Â·  94Comments

xscheiner picture xscheiner  Â·  73Comments

fabianschwarzfritz picture fabianschwarzfritz  Â·  48Comments

b0rski picture b0rski  Â·  66Comments

BrysonR picture BrysonR  Â·  91Comments