flow-typed / flow-typed Goto Github PK
View Code? Open in Web Editor NEWA central repository for Flow library definitions
Home Page: https://flow-typed.github.io/flow-typed/
License: MIT License
A central repository for Flow library definitions
Home Page: https://flow-typed.github.io/flow-typed/
License: MIT License
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.
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.
Probably related to #143
https://travis-ci.org/flowtype/flow-typed/builds/144216941
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.
I have been trying to create one for my own project.
If anyone else has started one, please do let me know. :)
@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.
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.
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
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:
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)
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
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?
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.
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)?
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 any
s/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.
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)
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
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.
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:
definitions
, my tooling worksjavascript-fatigue
project works... it creates me all the scruff I need to get down to work for a redux-project)playground
directory inside flow-typed
, which is set up with its own package.json
, similar to the cli
directoryAfter 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?
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?
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 😄
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?
Does adding this to the Axios class fix it?
declare class Axios {
create: <T>(config?: AxiosXHRConfigBase<T>) => Axios;
}
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).
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).
webpack is one of the most widely used Javascript library. It would be great to have Flow definitions for it.
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.
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
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)
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
?
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
I've made decent progress on this. Should be able to submit a PR soonish.
Heads up for anyone else.
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? :-/
The GroupBy operator is missing from the RxJS type definitions.
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).
👋 I was wanting to propose adding a simple .editorconfig
file so text editors with the plugin installed will automatically configure themselves to be consistent.
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.
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?
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! 🎉
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
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.
Takes way to long to run npm install -g flow-typed
. Need to look into this.
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 :-)
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
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.
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?
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?
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)
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?
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.