Release 3.0 #250
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 <[email protected]>
…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 <[email protected]>
* 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 <[email protected]>
* Allow resolver fn to be async * Changelog updates Co-authored-by: hwillson <[email protected]>
|
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.
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 withFiltermethod 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
[email protected]. It should not be merged until we're ready to release 3.0.