Let's take some wishes for major release. Here's my thoughts.
I think #299 is very needed.
I also think #321 is a no-brainer for a core higher order component.
I feel the reason it got closed is not good enough, it should be reopened. We can add it now and deal with future stuff in the future.
So I added a complete PR #357 that satisfies #321. I hope its good enough for next release.
Is this the roadmap for v1.0? If not, I'm curious what is needed to release a 1.0 version of this library.
@rnicholus no it's wishes of @TrySound and all the progressive humanity :-) BTW I think their are close to the part of real roadmap.
I assume that real roadmap also contains documentation, react fiber fixes, and deprecations of some rarely used enhancers.
One issue with including typings in the library is that you'll need many more major version updates than normal, as improvements in Typescript or Flow results in narrowing definitions over time (which causes breaking changes).
It's nice to make them official, but there's a tradeoff there.
remove per file hoc support (to prevent babel helpers duplicating). Tree shaking will help with bundles
it wont help commonjs consumers though if you remove per file hoc support, it will mean they need to go all in with recompose when importing even a single HOC
I've found some massive holes in the current @types/recompose typings that I've implemented fixes for. Do you want me to a submit a PR with updated, improved types here?
what is @types/recompose?
That's generated from the recompose folder on DefinitelyTyped. You'll want to submit the PR there.
I realize that those types are from DefinitelyTyped, but the very first post in this thread talks about bringing Typescript typings into the repo. I'm offering to do just that through a PR. Are you guys open to a PR for that? It's definitely better to have the types directly in the repo than in DefinitelyTyped IMO.
For flow we have libdef internally and we copy it into flow-typed repo, every time something has changed.
I dont like current behaviour but see no other way now. I think it will be possible somehow provide libdefinitions without copying.
I have zero knowledge about ts, and all the infrastructure around. If it will be done like current flow support - with tests and example we will accept such PR
With Typescript, you can simply include the types in the library and import them automatically along with the library. You don't have to copy them anywhere, simply publish them to NPM. If I have time I'll make a PR that brings in the types.
Over the last couple of days I've fleshed out a lot of the types for the library and the only ones that don't work great are due to limitations in the Typescript language itself.
@istarkov Why you add it locally? You can just keep it in flow-typed repo without copying.
To make sure that we have some kind of controlled libdef. As I dont like the idea that everyone in flowtyped repo can change your definitions.
Everyone still can and will. But you should take those changes and add to this repo. Are you fan of two way data binding?:)
I'm pretty sure that current flowtyped repo is some kind of intermediate step forward. And will be deprecated in near future. Until that time I can accept current pain.
I believe it's possible to add an index.flow.js file where you put the types, this would avoid the copy/paste hassle. Apollo client handles it this way https://github.com/apollographql/apollo-client/tree/master/src
Most helpful comment