Towards TypeGraphQL v2.0 #1418
Comments
MichalLytek
added
Help Wanted 🆘
Launch control checklist
|
This comment was marked as resolved.
This comment was marked as resolved.
|
@carlocorradini Comments in the code are not API docs. We would need to write full JSDoc and then show it in the |
|
Yup, I cannot find the issue from typescript repo where they propose to retain comments in JS :/ |
TypeScript issue: microsoft/TypeScript#14619 |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Any updates to the ETA? |
Nope 😅 |
|
Seems like the argument validation messages stopped showing which field caused it with v2.0, similar to #362. Is it a known bug? Note: validation still works, just the error message stopped showing the field that caused it. |
|
Field resolvers don't work with Apollo Federation v2. It seems that if you are resolving a field for a type that was resolved by a different subgraph the field resolver function will receive an object that looks like this instead of the Root dataValues themselves: {
_changed: {...},
_options: {...},
_previousDataValues: {...},
dataValues: {...},
}I had to write this decorator and apply it to all Field Resolvers to resolve the issue: export function DataValues() {
return (_target: any, _propertyKey: string, descriptor: TypedPropertyDescriptor<(...params: any[]) => Promise<any> | any>): any => {
const originalMethod = descriptor.value
if (!originalMethod || typeof originalMethod !== 'function') {
throw new Error('Method not found or is not a function')
}
descriptor.value = async function(...args): Promise<any> {
const callArgs = args.map((arg) => {
return { ...arg, ...(arg.dataValues || {}) }
})
const result = await originalMethod.apply(this, callArgs)
return result
}
}
} |
|
@MichalLytek not being able to use What can be done to get a release out that supports Could we get a |
@carlocorradini I don't see any changes in #1400 around |
|
@shellscape
All of the above errors do not disclose any sensible information, hence they shouldn't be hidden. If you really want to hide them, just catch the error and return a more generic one. |
great, those should be fine.
That's reasonable using this lib directly, not so much when using with the sister lib typegraphql-prisma. |
|
@shellscape |
|
yeah @MichalLytek @pauloendoh please what would be the replacement/alternative for this please, I have over 25 resolvers and it was more efficient to just colocate in the resolver folder and use the matcher to find it there. Is the only solution now to list all of them manually? |
@pauloendoh @okaforcj Since then, the node.js production deployments have changed, we now have plenty of new compilers, bundlers, etc. There will be a migration doc with a guide how to write a custom helper function that will accept an array of glob path strings and return an array of resolver classes that will work in common scenarios. Then it's community responsible to provide solution that works with Vercel, AWS lambda, docker and local dev env. |
|
Hi @MichalLytek I'm curious if is there a way to inject the following in the schema or |
|
@carlocorradini Thanks! do you guys have a sense of when it's gonna be released? |
|
@vany0114 This week it should be merged. |
|
@carlocorradini gotcha, in the meantime can you point me to where is that implemented to see if I can borrow it while it is released? 🙏 |
|
Simply run: npm uninstall type-graphql
npm install type-graphql@nextEasy peasy 😎 Copy paste the federation V2 example and you are good to go 🥳 |
|
I guess that would install the "unofficial" package and I'd like to avoid it, so if the code that extends the schema is not too complex I'd like to incorporate it on my own |
|
@MichalLytek not sure if I misunderstood but in this comment you say that the extend schema stuff is added automatically by the
However, I was reviewing the implementation and it seems it's not, also the documentation says it needs to be added in the schema. So I'm curious whether the opt-in to Federation 2 is really supported (or it's gonna be) by |
|
PR #1400 has been merged! 🥳😎🤩 |
|
Hello everyone, i am struggling to use the buildSchema function. Can someone tell me how to convert my glob path strings into resolver classes to use them in the buildSchema function. |
|
@RealSebbooo |
|
And what is the alternative so that i can import my resolvers from a different file? |
|
@RealSebbooo You should just use imports and resolvers array. Dummy require might produce weird issues and is not supported anymore. |
|
Just checking in because it's been a few months. How are things going on v2? |
|
@john-landgrave There is a pending refactor/rewrite of the subscriptions support as the old package is not maintained anymore: Then I need to make sure all issues requiring breaking changes are implemented, write some migrations docs and we should be ready to launch! |
|
The 4th beta release has been published! 🚀 As you can read in the changelog, it has new features for directives, validation and mostly subscriptions - now it uses the There's also a migration guide for this major and big breaking change: Feel free to leave here any feedback about the improved subscriptions support! 🙏 |
|
@MichalLytek thanks for the update! What version of Prisma will v2 require? |
|
@john-landgrave We're on the core TypeGraphQL repo, not the Prisma integration 😉 |
|
Whoops, you're right! I'll check issues and see if there's any news on that
over there. Thanks!
|
@MichalLytek, I appreciate the latest update. You mentioned that it should be compatible with any PubSub adhering to the interface. However, I've encountered an issue: when attempting to use RedisPubSub as PubSub, the Apollo client fails to connect. This makes me curious if there might be a bug within the new default Yoga implementation's internal assumptions. |
Did some debugging and this issue does not happen when Unfortunately, it surfaced another issue, the payload is always returning |
Yes, but
There is a redis subscription example on the repo. |
|
@MichalLytek thanks for the reply, and I will give another shot this week. I noticed that recent examples have transitioned from Apollo Server to Yoga, particularly because of the subscriptions, due to the graphql-subscriptions library being outdated. This shift raises a question: why has Apollo Server been phased out in the examples in favor of Yoga? Would it be possible to reintroduce an example that combines Apollo Server with some working subscriptions? Such an example would be invaluable for those of us looking to understand how Apollo Server can still be utilized effectively, especially in contexts where its subscription capabilities are essential. Thank you for considering this request. Your efforts in maintaining and evolving this project are greatly appreciated! |
|
@eduardolundgren So you should just follow the steps defined in the apollo-server docs: Examples uses Yoga because they are mostly a small showcase of the feature, an entry-level solution for newcomers. |
|
@MichalLytek, you were right. I kept my existing Apollo Server setup as described in the Apollo Server docs and just switched my subscription setup to use @graphql-yoga/subscription and @graphql-yoga/redis-event-target. Everything's working smoothly now. I also updated to 2.0.0-beta.6, so not sure if that also helped — thanks for the help! |
|
ℹ️ Quick update regarding 2.0 release ℹ️ The goal is to group all the breaking changes, because of major version bump. Today I've published the first RC release. It's also marked as the Before releasing stable 2.0, I would like to work on those issues and PRs: Also, we need to update readme, the backstory and maybe some docs/introduction, as in the last years many more GraphQL libraries came to live 😉 Stay tuned! 📻 |
and others
TypeGraphQL v2.0
The 2.0 release won't be a rewrite from scratch nor a breaking change in the existing API 👀
Basically, two main goals of this release are:
The 1) is mostly done (#1331) however it might need some attention around examples that might not work properly or still need updating deps (e.g. Apollo Server v4).
About the rest, all is described in the changelog:
https://github.com/MichalLytek/type-graphql/blob/master/CHANGELOG.md#unreleased
We're also working with @carlocorradini on reviving the repo and tools configuration that went out-of-date since the project was born 5 years ago, like TSLint has died and Gulp is not used anymore. See the work on #1400.
This should allow external contributors to work on the codebase, implement other fixes and features.
The current state of the art is published as a beta release -
npm i type-graphql@next:https://www.npmjs.com/package/type-graphql/v/2.0.0-beta.1
Stay tuned for more info! 📻
PS No ETA yet, the beta releases are stable enough to be used by users.
The text was updated successfully, but these errors were encountered: