-
Notifications
You must be signed in to change notification settings - Fork 133
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
Release 3.0 #250
base: master
Are you sure you want to change the base?
Release 3.0 #250
Conversation
Initial CHANGELOG placeholder for release 3.0.
* Add a(n optional) generic type map to PubSub. The class PubSub now has a generic type parameter so its methods `publish` and `subscribe` can be **optionally** type-checked by TypeScript. * Added part for PubSub generic. * Slight README tweaks to align formatting / adjust grammar a bit * Changelog update Co-authored-by: hwillson <hugh@octonary.com>
…ypes (#232) * fix(typings): return AsyncIterableIterator instead of AsyncIterator BREAKING fixes the type annotation of the abstract class PubSubEngine. According to the TypeScript type-defintion a `PubSubAsyncIterator` instance is actually a `AsyncIterableIterator` instead of an `AsyncIterator`. The typing of `PubSubAsyncIterator` is way more convenient as it allows iterating over it with the `for await (const foo of iterator) { doSth() }` syntax, which is super handy for filtering or mapping (See https://gist.github.com/n1ru4l/127178705cc0942cad0e45d425e2eb63 for some example operators). * remove iterall * rename asyncIterator method to asyncIterableIterator. * Slight tweaks based on graphql-js 16 changes * Changelog update Co-authored-by: hwillson <hugh@octonary.com>
* Failing case: pubsub asyncIterator should accept a readonly string[] * fix: Allow readonly triggers to be passed to PubSubEngine.asyncIterator * Changelog update Co-authored-by: hwillson <hugh@octonary.com>
* Allow resolver fn to be async * Changelog updates Co-authored-by: hwillson <hugh@octonary.com>
Any updates? |
Are there any more breaking changes planned? If not, could the release happen? Or even if, could the release happen? There's always the next major version for more breaking changes. |
@hwillson hey this has been blocking a major version upgrade of graphql codegen for us, any chance you could release soon? |
Patch graphql-subscriptions with changes from the [release 3.0 PR](apollographql/graphql-subscriptions#250) until it's merged
Same 👯 |
Any new improvements planned? What's holding you from merging it finally? |
Any news? |
1 year and still not ready? not to be rude or anything, what's the hold-up |
Any update would be appreciated? 🙏 |
Hello, I am reading the latest (V4) Apollo documentation that recommend using the There is a discussion in the graphql-codegen that generate code to use with Apollo that highlight that the issue is not on the generated type. Someone in the Codegen discussion gives a quick hack to fix the issue:
However, the hack is only for type. Doing:
Also fix the problem. The first comment of this thread is from |
export type FilterFn<TSource = any, TArgs = any, TContext = any> = (rootValue?: TSource, args?: TArgs, context?: TContext, info?: any) => boolean | Promise<boolean>; | ||
export type ResolverFn<TSource = any, TArgs = any, TContext = any> = (rootValue?: TSource, args?: TArgs, context?: TContext, info?: any) => AsyncIterator<any>; | ||
export type ResolverFn<TSource = any, TArgs = any, TContext = any> = (rootValue?: TSource, args?: TArgs, context?: TContext, info?: any) => AsyncIterator<any> | Promise<AsyncIterator<any>>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think to have proper typing there needs to be a distinction between the asyncIteratorFn
received as input which needs to return an AsyncIterator
and the withFilter
method that actually returns a AsyncIterableIterator
Should split ResolverFn
in 2 types to make the distinction.
@hwillson Is this something that is still on the agenda? Migrating to apollo v4 would be a lot more pleasant without conflcting types. |
This release PR will serve to collect significant new features, deprecation warnings, and minor breaking changes that we intend to release in
graphql-subscriptions@3.0.0
. It should not be merged until we're ready to release 3.0.