TypeStack ownership and next steps

[quentinus95]

@pleerock @NoNameProvided @19majkel94

Hi!

I've searched a lot around for a roadmap about the future of this library, the future of TypeStack and why nothing has really moved in this repo this year, but I've not been able to find a synthetic overview of who is doing what, is this repo dead, ...

I've seen in #333 and typeorm/typeorm#3267 that @pleerock had big plans for this library and the TypeStack ecosystem, but things are still blurry and I don't really understand what's happening, and if something is happening.

I've been using 19majkel94/type-graphql a lot recently, and it's a brilliant library focused on developer experience.

What about, first, making things a little more "institutional" by putting all the libs in typestack (as @pleerock suggested one year ago), renaming the libs as proposed, adding type-graphql in typestack to give more visibility to the whole project? (maybe also work on having a common website for all the documentations and share the donation budgets between the projects would help giving more visibility to all these libs)

Then, can you detail you plans (if any) for this lib and the relations between all the projects? (hope that this issue will get more responses than the others)

typestack/typestack looks defenitely abandonned, what about routing-controllers? I've searched for alternatives (currently I've only found loopback4 cc @bajtos, but sadly they are re-building the full thing and are missing a lot of features, especially in the validation and developer experience side, the APIs are not as intuitive and neat as what we can find here).

Thanks again for all the work you've brought to all these projects.

[MichalLytek]

The goal of TypeStack was to gather all the libs together to gain more attention and have a set of well-working together tools. It's not a framework, it's a simple CLI tool.

So, of course you can create an all-in-one framework/tool with CLI, quick setup, integration, common website with the documentations, etc. But I doubt that TypeGraphQL will become a part of the TypeStack organization.

It's not closed only to TypeORM and class-validator - it can work also with mongo (Typegoose), Prisma, NestJS, yup and others. From my perspective, it won't be developed under the TypeStack organization with shared donation budgets between the projects.

[quentinus95]

Thanks for your answer, @19majkel94

I think we share the same view about what TypeStack is, I personally see and use it as a set of independant but coherent components which may be used together or separatly, exactly the same way as I see Symfony Components. I'm not thinking about gathering everything under a full-stack framework, I prefer imagining a single website documentation including each component independant documentation and examples on how to use these components together.

I'm also thinking about ensuring projects are moving forward together and keeping a minimal backward compatibility (I have to admit that I like the monorepo approach of Symfony but I'm not sure it would be relevant here). It would help adding features and provide some assertions on how well these libraries are working together (today I'm stuck like many others with #384, for instance). Also I don't really agree on #436, using Nest means relying on a monolithic framework from which it would be hard to escape if project's activity decreases or stops. Using TypeGraphQL, on the contrary, allows to use this component in only a subset of the app (if required) and permits progressive migrations to and from TypeGraphQL.

As you stated, all these projects are sufficiently decoupled so they can be used everywhere and with any other lib, this is what was achieved in Symfony (for instance) as some of its components are used by other frameworks.

Don't you believe having all these projets together would help to resolve the forementioned issues as well as creating a better community of contributors and developers?

[RobinCK]

I also like routing-controllers most of all.
nestjs is ok but i hate angular structure and rxjs

[bajtos]

I've searched for alternatives (currently I've only found loopback4 cc @bajtos, but sadly they are re-building the full thing and are missing a lot of features, especially in the validation and developer experience side, the APIs are not as intuitive and neat as what we can find here).

@quentinus95 thank you for the ping and feedback on loopback-next. I admit our validation layer is a bit limited so far, we know about that. I am surprised that you find our APIs "not as intuitive and neat", would you mind giving us a more detailed feedback? I don't want to derail the discussion in this issue, I think it would be best to open a new issue in loopback-next repository.

Anyhow, different use cases require different solutions and APIs, it's not possible for a single framework to satisfy all developers. I wish you best of luck with your project, regardless of which framework you choose.

I am going to unsubscribe from notifications in this issue. Good bye 👋

[jraoult]

@19majkel94 thanks taking the time to answer some of @quentinus95 questions here but there is one I'm interested in:

[...]typestack/typestack looks defenitely abandonned, what about routing-controllers

For example, I noticed you implemented exciting things (like this: #289 ... 16 months ago) that we are still waiting for to be officially released.

What can we expect regarding the lifecycle for this (pretty cool) library? I want to know if there is a way we can help or if we should just move on.

EDIT: I think I found some answers there: #436 and #442 :) => move on

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.