flow-typed / flow-typed

A central repository for Flow library definitions

A repository of high-quality, third-party library type definitions for use with Flow.

---

⚠️ Version 4.0 will release soon! ⚠️

And with it comes new features, most notably the support for definition dependencies.

Learn how to add dependencies to a definition from the main branch docs which can be consumed with the v4 CLI.

$ yarn global add flow-typed@next
# or
$ npm install -g flow-typed@next

What's happening to master?

Nothing for the most part! CLI versions < v4 will still pull definitions from master so if you have library definitions that don't require dependencies we still recommend you contribute to master and it'll get periodically synced back to main for users >= v4.

Eventually we will deprecate master in favour of main.

---

Check out the quick start page in the docs to get started. It will walk you through installing typedefs, using them, as well as writing and including your own.

Huh?

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 of high-quality library definitions, tests to ensure that definitions remain high quality, and tooling to make it as easy as possible to import them into your project.

All you have to do when you add one or more new dependencies to your project is run flow-typed install. This will search the libdef repo and download all the libdefs that are relevant for your project and install them for you. After that, simply check them in and be on your way!

The CLI

The flow-typed npm package provides a CLI that includes several commands for working with this repository. The full list of commands is available in the docs .

FAQs

Before opening an issue, take a look at the FAQs. Chances are your question has already been answered! If not, don't hesitate to open an issue.

How Do I Contribute Library Definitions?

Just send a pull request! The documentation highlighted in CONTRIBUTING.md should give a detailed overview of how to raise a pull request following our best practices.

Contributing to the CLI

Bugfixes and improvements to the core CLI are welcome. If you'd like to contribute a new feature, consider opening an issue first to discuss it.

Active Maintenance Team

@AndrewSouthpaw	@Brianzchen	@GAntoine	@pascalduez	@villesau

flow-typed's Issues

Introduce an option to use a custom directory

Right now I need to have flow-typed directory in the root directory of my project. Would you consider to add an option providing a custom directory?

I'm trying to move as many infrastructure/tooling into a directory to keep the root clean.
Totally understandable if you don't want to go down that route, but still curious 😄

Related twitter conversation with @jeffmo https://twitter.com/nikgraf/status/753548419755540480

[CLI] Installing the CLI takes forever

Takes way to long to run npm install -g flow-typed. Need to look into this.

`module.exports` failure.

Is this declaration
https://github.com/flowtype/flow-typed/blob/master/definitions/npm/express_v4.x.x/flow_%3E%3Dv0.25.x/express_v4.x.x.js#L227 correct?

Eslint fails with Parsing error: Unexpected token on it. Not sure where to report it.

[CONTRIB] Make it easier to work on libdefs

Everytime I tried to write libdefs, I usually took one of my projects which are already using other flow-sources and then work in this project folder... which is not always ideal, since sometimes you want to use a more current version of flow, or you depend on other libdefs which will break then...

So I can think of these simple solutions:

• Either add the eslint / flowtype tooling to the root of this project, so whenever I work in definitions, my tooling works
• Create a cli command which turns an empty directory to a testing facility (similar to how my javascript-fatigue project works... it creates me all the scruff I need to get down to work for a redux-project)
• Create a pre-configured playground directory inside flow-typed, which is set up with its own package.json, similar to the cli directory

create method on axios is missing

Does adding this to the Axios class fix it?

  declare class Axios {
    create: <T>(config?: AxiosXHRConfigBase<T>) => Axios;
  }

When should tests be required?

We have the ability to write tests that exercise libdefs, but sometimes when there is only one definition file it can feel a bit redundant to have to specify a test for the libdef you just wrote.

Would it be a good idea to require at least one test file for each libdef (just to ensure the libdef typechecks with itself)?

cc @marudor @splodingsocks @ryyppy

[CLI] `validate-defs` should ensure that all flow-versions for a libdef are mutually exclusive

We plan to rely on this from the search and install commands, so we should make sure it's an invariant in the validate-defs command (which runs on every pull request).

(NOTE: I'm working on this this week, just wanted to log the work item here)

Dependencies between library definitions?

I started writing this out in the facebook/flow repo, but I think it actually might belong here. At least I think the discussion is more appropriate here, and might lead to tasks for Flow.

In a world where flow-typed manages library definitions for things like React, how should people write definitions for their libraries that depend on React types? Currently we allow library definitions to export global types, but I'm only interested in modular proposals.

I think it's worth separating libraries, like React, from environments, like node or browsers. It's possible that the same thing might solve both cases, but maybe not.

Library definitions currently describe compatibility with version(s) of the library itself and version(s) of Flow, but what about dependencies to other library definitions? What about node libraries vs. dom libraries?

The npm Package Hasn't Been Updated in a While

The current module version is 2.0.0 yet the latest published version is only 1.0.0.

I found it a bit confusing when the commands described under the "flow-type CLI" section did not work.

Does it make sense to publish 2.0.0 or 2.0.0-beta today?

If not, how about updating the readme in master to reflect 1.0.0?

Thanks.

[request] webpack

webpack is one of the most widely used Javascript library. It would be great to have Flow definitions for it.

[CONTRIB] Agree on an eslint ruleset?

As mentioned in #146, I would like to discuss if we want to start using some kind of linting ruleset, to make the source code style (definitions, tests, cli) more consistent...

IMO styleguides make a lot of sense, especially since a lot of people use very similar ones (e.g. Airbnb). Looking at the amount of definitions committed to this project, I think more consistency would help maintainability in the long run.

If you think this will only slow the project down and will bring no benefits, I will close this issue.

@jeffmo If there is a ruleset used by Facebook, we could eventually prefer that one,... otherwise I would be open for recommendations (I personally use Airbnb's ruleset).

[Meetup] Reactive 2016 Conference

As always, I create this thing as an issue, because really like to hangout with people contributing / using flow-typed & flow.

There will be the Reactive Conference in Bratislava, Slovakia on the 26th - 28th of October (https://reactiveconf.com/)

Has anybody planned to go there? Or does someone know if there will be any flow guys going?
Actually always wanted to meet @splodingsocks / @marudor ... but I guess you will be busy or too far away? :-/

Multiple test files

As some libdefs are quite big (e.g. ramda) it would be very nice to be able to break tests into separate smaller files. As we already have a folder structure I wonder if we could add an optional tests folder to keep everything clean. Then the test_... file could just import all the tests

[request] react-redux

Hello,

We have definition for redux in this repo, but a proper parameterized definition for connect would enforce the type in HOC wrapped component.

the behavior seems straightforward, but I am not sure how to parameterize mapStateToProps, mapDispatchToProps, mergeProps to maintain the typing.

currently

const mapDispatchToProps = (dispatch, ownProps) => {
  return {
    onClick: (data: MyType) => {
      dispatch(doSomething(data))
    }
  }
}

when using onClick, in the wrapped component, I am losing the the parameter information.

 const { onClick } = this.props;
  ....
  render() {
     onClick();
     onClick([]);
      onClick({});
       .....
  }

If I get help with this one function, I will create a pull request to make it into a proper module.

thanks,
bsr.

[LIBDEF] rethinkdbdash

I have been trying to create one for my own project.

If anyone else has started one, please do let me know. :)

[CONTRIB] Prefixing namespaces

Since a few PRs start adapting namespaces like $npm$bull or $npm$pad$type ... would it be a good idea to define namespace rules in CONTRIBUTING.md?

Cache a local git checkout rather than scanning libdefs through the GitHub API

Currently flow-typed install will hit the GitHub API multiple times for each call. Unfortunately, because the GitHub API is aggressively rate-limited, this means CLI users will run into issues with this approach fairly quickly.

Instead, we should probably just take inspiration from tools like Homebrew and manage a locally-cached checkout of the repo (say, in somewhere like ~/.flow-typed/repo-cache -- and I suppose % USERPROFILE% on windows).

`npm install -g flow-typed` fails on node v4.4.0 and npm 2.x

Created a new issue from the comment on #4.

Running on OS X El Capitan, npm version 2.15.2 and node v4.4.0, I get this:

$ npm install flow-typed -g
-
> [email protected] install /Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/flow-typed/node_modules/nodegit
> node lifecycleScripts/install

[nodegit] Fetching binary from S3.
[nodegit] Failed to install prebuilt binary:
{ [Error: Command failed: /bin/sh -c "/Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/flow-typed/node_modules/nodegit/node_modules/.bin/node-pre-gyp" install --fallback-to-build=false
module.js:327
    throw err;
    ^

Error: Cannot find module 'nopt'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/flow-typed/node_modules/nodegit/node_modules/node-pre-gyp/lib/node-pre-gyp.js:14:12)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
]
  killed: false,
  code: 1,
  signal: null,
  cmd: '/bin/sh -c "/Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/flow-typed/node_modules/nodegit/node_modules/.bin/node-pre-gyp" install --fallback-to-build=false' }
[nodegit] Building manually. (You'll be here a while.)
[nodegit] Regenerating and configuring code
[email protected] /Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/nodegit
├── [email protected] ([email protected])
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected])

[nodegit] Configuring libssh2.
ERROR - Could not generate native code
[TypeError: _(...).forEach(...).value is not a function]
[nodegit] Everything is ready to go, attempting compilation
events.js:141
      throw er; // Unhandled 'error' event
      ^

Error: spawn /Users/vesa/.nvm/versions/node/v4.4.0/lib/node_modules/flow-typed/node_modules/nodegit/node_modules/.bin/node-gyp ENOENT
    at exports._errnoException (util.js:870:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
    at onErrorNT (internal/child_process.js:344:16)
    at nextTickCallbackWith2Args (node.js:442:9)
    at process._tickCallback (node.js:356:17)
npm ERR! Darwin 15.5.0
npm ERR! argv "/Users/vesa/.nvm/versions/node/v4.4.0/bin/node" "/Users/vesa/.nvm/versions/node/v4.4.0/bin/npm" "install" "flow-typed" "-g"
npm ERR! node v4.4.0
npm ERR! npm  v2.15.2
npm ERR! code ELIFECYCLE

`groupBy` missing from rxjs types

The GroupBy operator is missing from the RxJS type definitions.

Add an "incomplete" libdef namespace for stale, unfinished libdef PRs

As @mirek pointed out over in #42, it's inevitable that we'll have some PRs submitted with an incomplete libdef (such that it doesn't fit the acceptance guidelines -- i.e. tests/too many anys/incorrect interfaces/etc) that the author doesn't have time to finish.

In these cases, its probably better to just merge these into a namespace that's excluded from the normal npm namespace so that someone might come along later and pick up where they've been left off (rather than starting from scratch).

Initially we can do this manually, but eventually we should build a bot to help manage this kind of SLA as well as doing the work of tweaking the PR and committing it properly.

[CLI] Need a `flow-typed create`

The process of creating all the directories and names and such (as described in CONTRIBUTING.md) is a bit tedious.

@nmote pointed out that we could probably make this a lot easier with some kind of flow-typed create command that prompts the user for lib name, lib version, flow version range(s), etc and creates files with TODOs in them (or whatever).

[CLI] Need a `flow-typed update-cache` command

Currently the cache updates itself if it's been more than 5 days since it was last used.
We should also include an update-cache command so users can quickly update the cache themselves.

(Also, while we're at it, might as well add a --update-cache flag to the install command too)

Need a `flow-typed install` CLI command

We need some kind of baseline command that can be used to just explicitly find + install a library definition for a given "package@version" and flow version. Something like flow-typed --flowVersion=0.22 [email protected].

It's pretty easy to add new commands to the CLI -- check out the other PRs (#15, #23) that do this as an example.

For matching a package@version to a libdef in the repository: I've actually already written getMatchingLibdefs() inside npm/src/commands/libdefsForPkg.js over in #23 . Given that that PR might warrant more discussion before it's ready to land, it seems fine to just steal that code and put it somewhere general for re-use (which I would then be happy to rebase #23 on top of if this lands first).

Other than that, this command would just create a directory called flow-typed and download/install the appropriate library definitions into it.

[LIBDEF] redux-saga

I will eventually start this, since this caught my attention when I was trying to type generators etc. while helping out another saga newbie...
If anyone already has something working, it would be cool to see the solution :-)

Related Issue: redux-saga/redux-saga#358

[Contributing] Add editorconfig for consistency with text editors

👋 I was wanting to propose adding a simple .editorconfig file so text editors with the plugin installed will automatically configure themselves to be consistent.

http://editorconfig.org/

[CLI] CLI should look at cwd and use locally-installed binary (if present)

One problem with npm install -g is that it installs an executable at a certain version -- whereas various projects could be built using/expecting a different version.

One way I dealt with this for the Jest CLI was to look at CWD and try to determine if we're currently inside a project that depends on the CLI (and, if so, delegate execution to the local version instead of the globally-installed version).

This should also help reduce the frequency with which people need to update their global CLI version.

How should these definitions be consumed?

As mentioned by @danvk, we need to figure out how best to instruct others to obtain and use these definitions. I'll be back next week to discuss more.

Which interfaces are already written?

It might be nice to get a list of interfaces to "seed" this project with.

As @marudor mentioned, he has collected a number of interfaces here:
marudor/flowInterfaces
I can vouch for a few of these.

I also found TechnologyAdvice's interface repo (which has overlap with marauder's) and a jQuery interface.

I'm pumped we're finally getting these together and am happy to help any way I can! 🎉

Tape definition file

Hey,
I am almost done with the tape libdef, but I am stuck with a specific kind of definition, so I hope I get some direction how I solve this...

Considering following usage:

import test from 'tape';

// 1
test.skip('mytest', (t) => { t.end(); });

// 2
test('myothertest', (t) => {
  t.end();
});

I could only get //2 running with this declaration:

declare module 'tape' {
  type TestBody = Function;
  type TestOptions = Object;

  type TestFn = (description: string, fnOrOpts: TestBody | TestOptions, fn?: TestBody) => void;
  declare module.exports: TestFn;
}

But I have no idea how I can export a class Function Test, which can be called as test(), but also supports the static function skip...

I tried something like this (actually a desperate attempt):

...
declare class Test {
  constructor(desc: string, fnOrOpts: TestBody | TestOptions, fn?: TestBody): void
  static skip(): void
}

...
declare module.exports: Test

But of course, this does not work as expected...

Any ideas?

Ramda declarations, destructuring imports

To grab the interface file I ran: flow-typed install ramda -f 0.26, then added a line to my .flowconfig to produce:

[libs]
decls
flow-typed/npm

I created a trivial test file...

/* @flow weak */
import { identity } from 'ramda'
console.log(identity(3))

And on type checking got...

handlers/scratch.js:3
  3: import { identity } from 'ramda'
              ^^^^^^^^ Named import from module `ramda`. This module has no named export called `identity`.

Looking at the file, it appears that all of the declarations are exported building up one class through mixins, which class is then the sole export. This, it seems, produces the frustrating result above. I can work around this by avoiding destructuring import:

import Ramda from 'ramda'
const { map, add, identity } = Ramda

// map, add, identity now all typed

I'm new to flow, so it's unclear to me whether this is an issue with the declarations in this repository, a result of some misunderstanding on my part, or a shortcoming of flow itself.

cc @alexeygolev @jeffmo. Thanks for your contributions so far.

[Test CI] Automatically comment on PRs that add `any` types

We want the libdefs in this repository to remain high quality. As such, we want to minimize any types as much as is reasonably possible. In some cases an any type of some kind (including things like Object, Function, etc) is unavoidable -- so we can't simply ban them altogether.

To minimize the number of unnecessary any types, it would be good to have Travis check for these and comment on any pull requests that add them -- pointing out that they should be avoided if at all possible.

Perhaps something like a --strict flag could be added to the validate-defs command that emits warnings on these kinds of things?

Only run changed Tests on CI

Probably related to #143
https://travis-ci.org/flowtype/flow-typed/builds/144216941

@jeffmo

Should this belong to a community org?

I'm glad to have this repo under my name. But would it be more appropriate to create a 'FlowCommunity' GH org and move it there?

[Test CI] Only run tests for files affected by a pull request

Currently we run all tests -- which takes quite a long time and definitely won't scale.
Instead, we should only run tests for libdefs that were touched in the PR

[Test CI] `validate-defs` should ensure that each npm package name is actually an npm package name

Currently all of our definitions are assumed to be valid npm package names, but we don't automatically verify this. (I've been verifying it as I accept PRs).

It would be good to automate this in the CI tests.

ESLint support?

Since I am currently trying to take a stab for the install command, I got annoyed really fast by the missing eslint support... is this something you left out intentionally, or should I create a PR for adding it?

redux-form

The FormConfig type doesn't allow settings to be passed from props.

I do this all the time say if the list of fields is dynamic I'll have a container that is connected to redux which creates the array of fields and passes it to the redux-form wrapped component.

See http://redux-form.com/5.2.4/#/api/reduxForm?_k=do3dix

Express definition file

Hello 👋

I'm working on a definition file for Express.

I'm new to Flow so progress is slow.

I'm hoping to track my progress here and maybe get some help. Thanks 😄

Shall we publish `-beta.0` of the CLI?

After a quick IRC conversation with @ryyppy and @marudor, it seems like we're ready to publish a beta version of the CLI at this point.

I've pushed the version in the package.json to 2.0.0-beta.0 so people can npm install -g it and start playing around.

cc @splodingsocks -- what do you think?

* flow-typed cache not found, fetching from GitHub...ERROR: Unable to clone the local cache repo.

I am not able to install at type definition. Not sure what is wrong with github (my internet access is ok and github is up - proof is this issue).

$ npm install -g flow-typed
/Users/MoOx/.nvm/versions/node/v5.11.0/bin/flow-typed -> /Users/MoOx/.nvm/versions/node/v5.11.0/lib/node_modules/flow-typed/dist/cli.js

> [email protected] install /Users/MoOx/.nvm/versions/node/v5.11.0/lib/node_modules/flow-typed/node_modules/nodegit
> node lifecycleScripts/install

[nodegit] Fetching binary from S3.
[nodegit] Completed installation successfully.

> [email protected] postinstall /Users/MoOx/.nvm/versions/node/v5.11.0/lib/node_modules/flow-typed/node_modules/nodegit
> node postinstall.js

/Users/MoOx/.nvm/versions/node/v5.11.0/lib
└─┬ [email protected] 
  ├─┬ [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ └── [email protected] 
  ├─┬ [email protected] 
  │ └── [email protected] 
  ├── [email protected] 
  ├─┬ [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ └── [email protected] 
  ├─┬ [email protected] 
  │ └── [email protected] 
  ├─┬ [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ └─┬ [email protected] 
  │ │   └─┬ [email protected] 
  │ │     ├── [email protected] 
  │ │     └─┬ [email protected] 
  │ │       └─┬ [email protected] 
  │ │         ├── [email protected] 
  │ │         └── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ └── [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├─┬ [email protected] 
  │ │ │ │ ├── [email protected] 
  │ │ │ │ └─┬ [email protected] 
  │ │ │ │   └── [email protected] 
  │ │ │ └─┬ [email protected] 
  │ │ │   ├── [email protected] 
  │ │ │   ├─┬ [email protected] 
  │ │ │   │ ├── [email protected] 
  │ │ │   │ ├── [email protected] 
  │ │ │   │ └── [email protected] 
  │ │ │   ├── [email protected] 
  │ │ │   └── [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ └── [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ └── [email protected] 
  │ │ └─┬ [email protected] 
  │ │   ├─┬ [email protected] 
  │ │   │ └── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├─┬ [email protected] 
  │ │   │ └── [email protected] 
  │ │   ├── [email protected] 
  │ │   └── [email protected] 
  │ └─┬ [email protected] 
  │   └─┬ [email protected] 
  │     └── [email protected] 
  ├─┬ [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ └─┬ [email protected] 
  │ │   ├── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├── [email protected] 
  │ │   └── [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ └── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ └── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ └── [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├─┬ [email protected] 
  │ │ │ │ └── [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ └── [email protected] 
  │ │ └─┬ [email protected] 
  │ │   └── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ └── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├── [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ ├── [email protected] 
  │ │ │ └── [email protected] 
  │ │ └─┬ [email protected] 
  │ │   ├── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├─┬ [email protected] 
  │ │   │ └── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├─┬ [email protected] 
  │ │   │ └── [email protected] 
  │ │   ├── [email protected] 
  │ │   ├── [email protected] 
  │ │   └── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ └── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ ├── [email protected] 
  │ └── [email protected] 
  ├── [email protected] 
  ├── [email protected] 
  ├─┬ [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ ├── [email protected] 
  │ │ └── [email protected] 
  │ ├── [email protected] 
  │ ├─┬ [email protected] 
  │ │ ├─┬ [email protected] 
  │ │ │ └── [email protected] 
  │ │ └── [email protected] 
  │ ├─┬ [email protected] 
  │ │ └── [email protected] 
  │ ├── [email protected] 
  │ └── [email protected] 
  ├── [email protected] 
  └─┬ [email protected] 
    ├── [email protected] 
    ├─┬ [email protected] 
    │ └── [email protected] 
    ├── [email protected] 
    ├─┬ [email protected] 
    │ ├── [email protected] 
    │ └── [email protected] 
    ├─┬ [email protected] 
    │ └─┬ [email protected] 
    │   └── [email protected] 
    ├─┬ [email protected] 
    │ ├─┬ [email protected] 
    │ │ └── [email protected] 
    │ ├─┬ [email protected] 
    │ │ ├─┬ [email protected] 
    │ │ │ └─┬ [email protected] 
    │ │ │   └── [email protected] 
    │ │ ├── [email protected] 
    │ │ └─┬ [email protected] 
    │ │   └── [email protected] 
    │ ├── [email protected] 
    │ └── [email protected] 
    ├─┬ [email protected] 
    │ └─┬ [email protected] 
    │   ├─┬ [email protected] 
    │   │ ├── [email protected] 
    │   │ ├─┬ [email protected] 
    │   │ │ └── [email protected] 
    │   │ └─┬ [email protected] 
    │   │   ├─┬ [email protected] 
    │   │   │ └── [email protected] 
    │   │   └─┬ [email protected] 
    │   │     └── [email protected] 
    │   └── [email protected] 
    ├── [email protected] 
    ├── [email protected] 
    ├── [email protected] 
    ├── [email protected] 
    └─┬ [email protected] 
      └── [email protected] 


~/myproject master* 1m 49s
❯ flow-typed install -f 0.27 [email protected]
 * flow-typed cache not found, fetching from GitHub...ERROR: Unable to clone the local cache repo.
UNCAUGHT ERROR: Error: authentication required but no callback set
    at Error (native)

Doesn't support '>=' in top-level directory

From https://travis-ci.org/flowtype/flow-typed/builds/133284414

Found some problems with bull_>=v0.7.2:
  * 'bull_>=v0.7.2' is a malformed definitions/npm/ directory name! Expected the name to be formatted as <PKGNAME>_v<MAJOR>.<MINOR>.<PATCH>

The docs say:

Where 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, and it is also acceptable to put >= or <= in front of the v to indicate a range of versions.

bull has both 0.7.x and a 1.0.x releases...the interface is largely the same between the two. I'll bump up to 1.x.x to unblock myself, but this should probably be supported?

[COMMUNITY] React-Europe

I saw that @jeffmo announced a talk for React-Europe 2016 about flow and that's why I wanted to ask if anyone here is also going there and keen to meet up? Would be cool to talk about flow, the future and other stuff :-)

CLI and fetching compatible versions of libdefs

Our current plan leads to some possible unpleasant behavior in certain circumstances. @jeffmo provided this example yesterday:

If you have version underscore@^1.0.0 in your pkg json, and we have two libdefs for underscore: v1.0.x and <=v1.1.0 -- which should we choose?
we probably always want to choose the lowest compatible libdef (since npm doesn't guarantee it will install the highest-compatible version of 1.0.0 -- only some compatible version. So either 1.0.0 or maybe 1.1.0)

Describing a problem scenario:

(1) Person A downloads your pkg and npm installs. They get [email protected]. (2) [email protected] is published (3) Person B downloads your pkg and npm installs. Well now they'll get [email protected]
We'll say 1.1.0 has a new function in it
It becomes safe for person B to use that new function, but if person A rebases or whatever -- Flow won't know that it's ok to use the function and will give an error

Here are some possible solutions:

1. We add a section to the package.json for libdefs that gets updated when flowtyped installs new libdefs. This section would lock the version down to the exact git hash it fetched from github.

Then flowtyped would check the package.json for existing libdef resolutions before it tries to match using semver. If it finds an entry there, it uses that file exactly, and doesn't try to do any automatic resolution

A problem with that idea would be keeping the libraries in sync. By not locking down the libdef version, flowtyped could always try to fetch the appropriate version for what's listed in the package.json. But it seems like that could be resolved by adding a flowtyped update command, which would check all of your locked down libdefs against your listed node packages, and offer to upgrade any that no longer match (as long as there exists a compatible definition on flowtyped)

1. We could take the homebrew approach, and only have the latest version of any libdefs present in the repo. If an older version of a libdef is desired, it can be fetched from its specific historical commit.

Though I like the simplicity of that approach, I think it makes for a worse user experience, and we'd basically be ignoring flow compatibility concerns

A big downside to that approach is that it'd be practically impossible to fix (or augment) old libdefs for old libraries.

Also, it'd be very difficult to handle these dependencies: #16

Cannot call `map` from Ramda with same arity but different signatures

The way the typings for map in Ramda currently work, if you try and call map in two places with the same arity (arguments passed one-by-one, or both at once), but different type arguments (array, object, functor), Flow will blow up.

For example, try adding

const zs: {[key: string]: string} = _.map((x) => x.toString(), { a: 1, b: 2, c: 3 })

below here

and running the tests

cc/ @alexeygolev

[tests] Idea: Use a runtime test library for tests

@alexeygolev showed an interesting way of writing tests for the ramda libdef over in this pull request: #95

Basically the idea is that we could have the test runner (a) typecheck the test code (contains type asserts just like we have today) and then (b) actually run the tests (using the actual npm library) to make sure they pass.

This could help bridge the uncertainty gap between a libdef and it's actual implementation.

Licensing

Should we just pick a license (MIT?) and just say that all contributed definitions adopt that license?

This question pertains to the discussion happening in #4, but I didn't want to get the conversation there off track.

Tests reject `flow_all`

When running ./run_def_tests.sh rxjs on newly-added rxjs declarations:

Found some problems with /Users/nmote/repos/flow-typed/definitions/npm/rxjs_v5.0.x/flow_all:
  * '/Users/nmote/repos/flow-typed/definitions/npm/rxjs_v5.0.x/flow_all': Invalid major number: 'undefined'. Expected a number.
  * '/Users/nmote/repos/flow-typed/definitions/npm/rxjs_v5.0.x/flow_all': Invalid minor number: 'undefined'. Expected a number.
 * '/Users/nmote/repos/flow-typed/definitions/npm/rxjs_v5.0.x/flow_all': Invalid patch number: 'undefined'. Expected a number.

These errors disappear if I rename the flow_all folder to flow_>=v0.25.0

[LIBDEF] prismic.io

I've made decent progress on this. Should be able to submit a PR soonish.

Heads up for anyone else.

Flow types for Flow JSON output

Could we have Flow types for the output of the JSON versions of various Flow commands? I'm happy to contribute some but obviously these shouldn't be in the npm namespace, so I'm not sure where they should go. If you help me figure that out I'll put up a PR.

[request] d3

Hi guys,

Is anybody working on definitions for d3.js? There is definition in DefinitelyTyped, but it's huge! (3k lines).

Is there any way to convert this stuff automatically?