Future of TypeGraphQL-Prisma
MichalLytek opened this issue · comments
As you may already know, Prisma recently went through the restructuring process:
https://www.prisma.io/blog/restructure-announcement-1a9ek279du8j
The layoff also reached freelance OSS contributors, that were sponsored to work on the Prisma-ecosystem tools, like typegraphql-prisma itself.
What does it mean is that I won't be able anymore to develop and maintain this project in such an active way like for the last 3 years.
It's not like I won't be maintaining the project anymore but I will be able to only provide support like bug fixes or new Prisma version compatibility upgrades.
However, all the fancy features that requires more work/hours won't be implemented by me in the near future.
But I hope that the community around this project is huge and active enough that they will be implemented by Pull Request from the external contributors 😉
Thank you for all your support and let's keep typegraphql-prisma alive together! 💪
@MichalLytek I think the community here is likely all willing to help keep this project going. I think what would be helpful in order for the community to be able to help in the maintenance and features work would be to have a roadmap of items that were thought up or ideas that would be useful for typegraphql-prisma which would give the community around this package a starting point to contribute.
@MichalLytek sorry to hear that you've lost the financial support to maintain this project. I suspect there are numerous engineers who use this project who would be willing and able to contribute - I think the biggest challenge will be whether and how you open the doors to contributions. I've seen many projects die simply because the only person who has the power to respond to issues and PRs ceases to respond as it loses their focus, and folks end up desperately forking the repo to unblock things. Currently I note that you're the only person who's contributed (the other 9 contributors having contributed a dozen lines between them).
Do you already have in mind some contributors that could be entrusted to help you manage the contributions you hope will start flowing in? are you planning to put together some contribution guidelines? do you have the time or do you have people who can help you with the roadmap?
Was there a specific reason this announcement hasn't been made earlier, even though the "Prisma restructuring" was announced in January?
We migrated to typegraphql-prisma between January and May and use it in production because of its ease of use. Now feel like we have to migrate to something like nexus or pothos once again
The only one complaining here could be me, working in March and April pro bono, because Prisma team forgot to tell me that they had to cancel sponsorship.
So yes, the reason is that they haven't informed me on time.
I think what would be helpful in order for the community to be able to help in the maintenance and features work would be to have a roadmap of items that were thought up or ideas that would be useful for typegraphql-prisma which would give the community around this package a starting point to contribute.
Do you already have in mind some contributors that could be entrusted to help you manage the contributions you hope will start flowing in? are you planning to put together some contribution guidelines? do you have the time or do you have people who can help you with the roadmap?
Basically, all the main work is related to keeping this generator in sync with all the new Prisma features, like fieldReference, etc.
I don't have any roadmap or plans for other big features not related to that:
- decorator approach for Prisma schema won't happen as Prisma Team is against and there's no SDK to build the schema by code
- custom attributes might happen soon, so we can replace them instead of using comment
/// @typegraphqlhack applyEnhanceMapand other function are a bit weird API, and some features might require more runtime configuration - that's why I was thinking about some static config file approach that would be read by the generator or embedded in the generated code
That's all I can think of now 😉
If someone want to work on some issue, please ping me in the proper issue thread to discuss the approach or scope.
If someone want to help in other way, I would ask to check Prisma releases changelog to see which features or preview flags are not supported and create proper issues here, so others or I can handle them.
I would say the top priority is to make all existing features work with new Prisma releases.
Then to make all the new Prisma features work.
In the end, all the small things that makes a better DX or that are not related to Prisma changes, like performance issues, ability to work with huge schemas, replacing ts-morph with other solution, etc.