re: with a TypeScript or Flow frontend codebase? VIEW POST

re: I read the GitHub issue all over again and I have some observations and questions (mostly questions :D) What you propose would be a rewrite or so...

Agreed that "the pique devs interest" shouldn't be a deciding factor. That was just a side note.

What you propose would be a rewrite or something like "from this day forward all the new client code will be written with TS/Flow" ?

You can enable TypeScript (TS) and all existing JS is considered valid in TS. From there you can incrementally add types. If we went the TypeScript route, I would probably promote TS with Babel since this is the easiest way to get started when migrating an existing codebase. Perhaps longterm the TypeScript compiler could be used. As far as I know there are only two things you can't do with the babel preset for TypeScript. const enums and the use of namespaces.

In regards to Flow, JS is valid there as well and types could be incrementally added that way as well.

What happens to third party libraries that do not provide types or support for TS or Flow? Can they be used? Will they require the user to define all the unspecified types?

3rd party libraries that are written in TypeScript do not have this issue as they ship (or should be shipping with their types). For everything else, there is a project called DefinitelyTyped.

DefinitelyTyped / DefinitelyTyped

The repository for high quality TypeScript type definitions.


The repository for high quality TypeScript type definitions.

Also see the website, although information in this README is more up-to-date.

You can also read this README in Spanish, Korean, and Russian!

Current status

This section tracks the health of the repository and publishing process It may be helpful for contributors experiencing any issues with their PRs and packages.

If anything here seems wrong, or any of the above are failing, please raise an issue in the DefinitelyTyped Gitter channel.

Join the chat at

What are declaration files?

See the TypeScript handbook.

How do I get them?


This is the preferred method. This is only available for TypeScript 2.0+ users. For example:

npm install --save-dev @types/node

The types should then be automatically included by the…

This is the repo that allows you to install types via npm, e.g. npm install @types/axios-case-converter. Most 3rd party libraries have types for them thanks to the TypeScript community.

For everything else, you can add types in your project for a 3rd party library, if necessary. Even better, put a PR up to DefinitelyTyped πŸ˜‰

In regards to Flow they have 3rd party types as well via the flow-typed project, but not as many as TypeScript.

flow-typed / flow-typed

A central repository for Flow library definitions

Flow Logo

Travis npm

flow-typed is a repository of third-party library interface definitions for use with Flow.

You can grab definitions directly from this GitHub repo, or you can use the CLI (currently in beta) to install a libdef for a given library:

$ yarn global add flow-typed
$ cd /path/to/my/project
$ yarn install
$ flow-typed install rxjs@5.0.x
'rxjs_v5.0.x.js' installed at /path/to/my/project/flow-typed/npm/rxjs_v5.0.x.js


When you start a project with Flow, you likely want to use some third-party libraries that were not written with Flow. By default, Flow will just ignore these libraries leaving them untyped. As a result, Flow can't give errors if you accidentally mis-use the library (nor will it be able to auto-complete the library).

To address this, Flow supports library definitions which allow you to describe the interface of a module or library separate from the implementation of that module/library.

The flow-typed repo is a collection…

I imagine the same thing can be done in Flow where if necessary, you can write types in your app that are missing for 3rd party apps. For all the Flow experts out there, please chime in.

I really like the idea of using Visual Studio code's "ts-check", it could be a starting point helping to cleanup the code and migrate the code that's not on ES2015+ to it before one commits to TS or Flow.

πŸ‘ if people are using VS Code. If not, I don't think this works.

Would Flow be less of on/off switch transition?

Not sure I understand the question. Do you mean is it less invasive than TypeScript?


Not sure I understand the question. Do you mean is it less invasive than TypeScript?

If the transition would be more gradual

They'd be the same in term of doing things gradually.

I read this post, largely agreed with it, but wanted to give this some thought.

I feel like my role needs to be that of allowing progress to happen while trying to re-enforce core values. My biggest opinion on frontend to this point has been to try to time the technology appropriately. I just haven't wanted to be on the front of too many waves even if they are great choices in and of themselves.

I'm probably down with this, and I feel like this could be a fairly community-led initiative. Me and the rest of the team just have to come up with a good shared understanding of the path forward.

We still have a whole bundle of JS that is definitely "legacy" at this point. So overdue to be made modern, so a pretty decent time to put some work into all of this, add better testing and make things more concrete on the frontend in general.

code of conduct - report abuse