NOTE: The flow-typed
CLI is currently in beta. Please try it out and report any issues you encounter. Thanks!
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:
$ npm install -g flow-typed
$ cd /path/to/my/project
$ flow-typed install -f 0.30 [email protected] # `-f 0.30` specifies the Flow version we're using for this project
'rxjs_v5.0.x.js' installed at /path/to/my/project/flow-typed/npm/rxjs_v5.0.xjs
When you start a project with Flow, you might want to use some third-party
libraries that were not written with Flow. Flow is usually able to work its
way around this, but at the unfortunate cost of typing those third-party modules
as any
. 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 of high-quality library definitions,
tests to ensure that they remain high quality, and tooling to make it as easy as
possible to import them into your project.
Just send a pull request!
All definitions sit under the /definitions folder. They all must follow the following naming format:
<NPM_PACKAGE_NAME>_v<VERSION>
/flow_v<VERSION>
/<NPM_PACKAGE>_v<VERSION>.js
Where <VERSION>
is a semver version number with all of MAJOR, MINOR, and PATCH
version numbers included. x
is an acceptable wildcard in place of any of the
three version numbers.
For Flow versions it is also acceptable to put -
in front of the <VERSION>
to indicate "up to and including this version", or after the <VERSION>
to
indicate "this version and anything after", or you can put two versions with a
-
in between to indicate "anything including or between these 2 versions".
Note that -
ranges are not supported for npm package versions, only x
wildcards. (Library interfaces are rarely identical across major versions)
Example filename:
underscore_v1.x.x/flow_v0.13.x-/underscore_v1.x.x.js
This is a library definition for all "1.x.x" versions of underscore that works with any version of Flow >= v0.13.
We structure files this way is to enable automated testing and tooling.
Tests ensure that library definitions continue to work as expected and the
flow-typed
tooling ensures that it's as easy as possible to find and install
library definitions.
When you contribute a new library definition (or make a change to an existing one), you should include tests with your change.
Tests are simply test_*.js
files that sit next to the library definition
file. Their purpose is to exercise the defined library and ultimately produce
zero Flow errors for each version of Flow that the libdef is specified as
compatible with.
Often it is useful to test that a particular usage of a library definition
does produce an error. For this you can write some code that produces a Flow
error and just put // $ExpectError
on the line above where the error is
produced. This will tell the test runner that an error is intentional and
expected on the following line.
The flow-typed
npm package provides a CLI that provides several commands for
working with this repository:
Verifies that all files under the /definitions/
directory are structured
properly. It does not run tests, it only asserts that file and directory
names match the expected conventions.
Runs all compatible versions of Flow over the each library definition with it's tests to ensure that the tests pass as expected.
Note that this command assumes that the /definitions/
directory is correctly
structured. You can always verify the structure with the
flow-typed validate-defs
command.
By default flow-typed retrieves all available libdefs from its related upstream repository. To make this process more efficient, those libdefs will be cached to your local filesystem. Usually, the cache will automatically be updated after a certain grace period during a libdef installation, but sometimes it is useful to do this update manually. Use this command if you want to download the most recent definitions yourself.
The debug flag will output additional (error) information, which can be useful for bug-reports.
Scans the specified package.json
, looks for any compatible libdefs in the
flow-typed
github repo, and prints a JSON list of URLs for each that is found.