-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lodash #42
lodash #42
Conversation
Would love to see The auto-currying functions are hard to type, not sure how we tackle this, also I was looking for a way to make function composition with Of course, I will help wherever I can, but these kind of super-generic function declarations are tough. |
@marudor thanks a lot for this. I'd like to help you with tests to make it merged. But as it's quite a lot of work to do, and work of different people could overlap, I'd propose the following flow: 1 - every method is tested in an appropriate test file. Does this make sense? |
Considering a fact that flow-typed is in beta, wouldn't it be better to merge definitions as they are from this PR (and others) to speed up the process? I'm sure people will "cherry-pick-commit" fixes much faster. At the moment definitions live in different branches which makes it very hard to contribute. Instead of waiting for perfect version, we could have something to work on, even if it's not confirmed 100% correct. Later we can add some stability flag or coverage report but for now I think just merging not-100%-covered definitions would be a win for the project. |
@mirek: Only the CLI is in beta -- the definitions are real :) Moreove, it's important that tests pass always -- otherwise we'll dig ourselves into a corner where only some definitions are high quality and others aren't. Id say it's ok to submit partial libdefs with intent to come back and fill in more API surface area later, but tests and versioning and such if the submitted surface area are pretty important even now. |
What about creating some sort of "sandbox" directory which mimics "definitions"? The focus should be on minimising size of PRs and making contributions easy. Without this kind of mechanism what are people doing? They look for things like Some people will dig deeper and see lodash in PR. Hanging there for 3 months, not much activity. They'll copy paste it to their project. Comment out or fix things that are broken and wait for new version. They won't commit back their changes for sure. The thing is that if people are able to install incomplete definitions (with On the flow-typed side - it's much easier as well, small patches that you can cache and run in your head can be accepted very quickly. The whole thing will move forward. |
Also worth noting that we aim for quick turnaround on PRs that pass tests . In this case, @marudor had a large number of libdefs that were around before flow-typed...so getting through those takes some time. In the future it's more likely that we'll have a more steady stream of libdefs written with flow-typed in mind (and thus tests + versioning, etc) -- so hopefully those will land more steadily. We should probably prioritize this particular one higher for turn-around than others tho (given than lodash is pretty popular) |
(sorry, I made the second comment without seeing that you'd already responded)
That's not a bad idea. We could move PRs there after some SLA of non-responsiveness rather than just closing them (this inevitably happens on every GitHub project occasionally). I also like the idea of excluding them from search/install results in the CLI without a special I'll make an issue to track this |
PSA: The updated definitions are found at https://github.com/marudor/flowInterfaces/blob/master/packages/iflow-lodash/index.js.flow |
I've updated it and reused the underscore tests. |
add gitter chat badge
No description provided.