Routing-controllers: discussion: call for maintainers and future plans

[jotamorais]

It is clear that we need help maintaining this project.

TypeStack projects/repositories are used in a lot of production environments today and the size of the code base as well as the issues, backlog and future project direction that we have to review - it all deserve more attention then it's currently getting from me.

I'd like to suggest a couple of things:

Maintainers:

We can leverage Github's Teams and perhaps create different teams and associate them with the different TypeStack projects/repositories and grant proper permission to individuals on those teams and to the repositories those teams would be associated with. Example:

TypeStack
    └── Core
        ├── class-sanitizer
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── class-transformer
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── class-validator
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── microframework
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── model-controllers
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── one
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── routing-controllers
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── socket-controllers
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        ├── typedi
        │   ├── maintainer-team
        │   ├── reviewer-team
        │   └── triage-team
        └── typestack
            ├── maintainer-team
            ├── reviewer-team
            └── triage-team

We could then assign individuals to those teams (preferably individuals that are already top-contributors of those respective projects/repositories) and grant the appropriate permission (we could check each project for the active contributors - members that haven't been active on TypeStack for the last year, wouldn't be considered).

If you are still interested, let us know your thoughts. If not, no hard feelings and thank you for your critical contributions.

Note that I will not be withdrawing from the project at all. TypeStack projects are very dear to me, but I need help.

Project Management

I think we have to define clear standard project management practices such as:

• 
  
  
  
  • Clear release cycle and respective plan and roadmap
  
  
• Project board for each project
• Issue template (with checklist or steps on how to reproduce the issue, actual result, expected results, etc)
• PR Template (with checklist for test coverage, documentation, samples, etc)
• Increase continuos Integration
• Adoption of Continuous Deployment to NPM, based on release/tag creation

Future state & roadmap

We should also reconvene and analyze the projects goals and make sure we have more adoption (from usage and development contribution perspectives). There are a number of things that we can do on this front:

• Reevaluate the roadmap and also existing features and check what can be deprecated, removed and what should be implemented or changed
• Static documentation generator or wiki, for live documentation (we could use things like docsify or Slate, for example
• A TypeStack website, with references to features, documentation and samples

If you have any comments or alternative solutions, let me know.

[rustamwin]

Bold step :muscle: Already there are some contributors @vlapo - class-validator, I'm - socket-controllers.
My additions:

• Create funding (Github sponsors, OpenCollective)

[ytetsuro]

I think it's a very good idea.

I think that if the triage and the criteria the reviewer are clarified in the document, there will be more contributors.

[OBQun]

I'm going to study typedi.
And plan to translate the document to chinese : )

[dsbert]

Can you please clarify how 'active in the last year' is defined? Is this actual merged code, open pull requests, comments on issues?

[ivanjeremic]

I saw some time ago that someone forked microframework and uses it in production, it is also more active than the original, but I can't remember the name and the project, can anyone confirm this? Btw. is routing-controllers a replacement for microframework?

[serchtul]

Are there any plans on specific dates for this to happen? I think it's a good idea but I don't see any clear progress, so I wanted to ask.

In my case, I am very interested in contributing to class-validator but I haven’t just yet, so I am interested in doing so as soon as the class-validator teams are established.

[jotamorais]

I still don't have full permission in all repositories and that is slowing things down.

The initial plan I suggested was to make as easy as possible to contribute, while still maintaining project's quality and backward compatibility as much as possible.

I believe the fastest way to make progress will be to establish a clear path to resolve/close all the open and pending issues and PRs. In other words, the plan has to be:

1. Fixes should only be pushed to main branches via PRs
2. Triage and integrate open/old PRs first
3. Triage and open new PRs to fix old open issues
4. Create GitHub issues/discussions with the community to establish a roadmap for TypeStack projects as a whole.

The bullet points listed above have tangible/achievable goals and have enough to get us started and put in a better condition to catch up with the community needs and from there, we start adding new features and improvements

[dan-barrett]

I've often wondered if this is something Microsoft would consider supporting- financially or with a team of their own. I suspect the typescript team does not have the bandwidth currently, but I think we should at least put it on their radar that there are a number of TS projects that are important to the community that need backing.

It doesn't look like I can tag anyone from the Typescript team in here, but @jotamorais, you should consider reaching out to https://github.com/RyanCavanaugh to see if he knows anything about the internals at Microsoft that would move the ball forward on that.

[jotamorais]

I've often wondered if this is something Microsoft would consider supporting- financially or with a team of their own. I suspect the typescript team does not have the bandwidth currently, but I think we should at least put it on their radar that there are a number of TS projects that are important to the community that need backing.

It doesn't look like I can tag anyone from the Typescript team in here, but @jotamorais, you should consider reaching out to https://github.com/RyanCavanaugh to see if he knows anything about the internals at Microsoft that would move the ball forward on that.

This is actually a good idea. I will reach out to Ryan (or other that he might point me to) and hear their take on this.

Thank you!

[jotamorais]

I've often wondered if this is something Microsoft would consider supporting- financially or with a team of their own. I suspect the typescript team does not have the bandwidth currently, but I think we should at least put it on their radar that there are a number of TS projects that are important to the community that need backing.

It doesn't look like I can tag anyone from the Typescript team in here, but @jotamorais, you should consider reaching out to https://github.com/RyanCavanaugh to see if he knows anything about the internals at Microsoft that would move the ball forward on that.

@RyanCavanaugh,

I will try to tag you here and see if you can read the suggestion gave by @dan-barrett - I also sent a message to you on a different platform.

Looking forward to hearing from you.

[rustamwin]

My additions:

• I would suggest creating a community chat (including the core team) on slack or discord. @jotamorais

[RyanCavanaugh]

Hey folks, thanks for the ping. Regarding personnel support from Microsoft's side, this isn't something within our scope of work. Generally we're only able to provide any investment for very tactical efforts (e.g. ESLint integration, specific work in ts-loader around TS project references) with broadly-adopted ecosystem features where we're providing specific subject matter expertise.

In terms of financial support, you can read about Microsoft's FOSS find at its README; this is the single point of contact for funding from Microsoft on FOSS projects.

Thanks!

[jotamorais]

Thanks for the quick reply, @RyanCavanaugh.

I noticed that one of the first requirements for the FOSS funding is for the project to be used by Microsoft. Does Microsoft uses any of the TypeStack projects (internally or as part of any product/project)?

Aside from the funding topic, would Microsoft (and more specifically the TypeScript team), be interested on partnerships to align work on roadmaps, communities expectations and the like?

[jotamorais]

My additions:

* I would suggest creating a community chat (including the core team) on slack or discord. @jotamorais

@rustamwin we already have the Gitter channels.

Or did you mean something else?

[rustamwin]

Or did you mean something else?

I think that slack and discord are the most popular and active at the moment.

[RyanCavanaugh]

I can't speak for Microsoft as a whole, but I'm not aware of any projects using TypeStack. Given the number of projects using TS in some capacity, we're not able to engage with individual projects/efforts on alignment.

[jotamorais]

I can't speak for Microsoft as a whole, but I'm not aware of any projects using TypeStack. Given the number of projects using TS in some capacity, we're not able to engage with individual projects/efforts on alignment.

I see. Well, we appreciate your inputs and direction given for the funding questions.

[dan-barrett]

Thanks for your input @RyanCavanaugh . I think my ask is a little different than that specific FOSS fund. In fact it's more broad than TypeStack and this thread; I'm just taking advantage of a relevant thread to surface something many of us have considered for a while. I think my ask is aligned with Microsoft's business strategy, your personal interest in seeing Typescript flourish for the long haul, and our interests as a community in building stable full-stack applications in what has become my favorite language. My ask is only that you bubble up what follows to the powers that be inside the Microsoft organization.

For obvious reasons, Typescript's first home was the front end. And given the nature of the playing field there, a handful of large web companies lead the way in library development. This yielded fantastic stable frameworks and libraries for the front end. But as Typescript has matured, we're seeing a push for the full-stack use case. I work for a company that is an early adopter of full stack Typescript. And for a company like mine to commit to using Typescript up and down the stack, we need build tools, a server framework, an ORM, and all the little libraries in between that glue everything together. There's an incredible organic community that has supported this movement; indeed they are the prerequisite for what we're even trying to accomplish.

None of these libraries have the same adoption rate as Angular or React or any of the front-end use cases- yet. But already the npm pull-frequency of many of these libraries is only one or two orders of magnitude away. Full stack Typescript is coming and we're excited for it. That said, many of these libraries (though not all) are plagued with the kinds of problems you'd expect in young open-source software packages: poor or outdated documentation, slow issue resolution, and sometimes disappearing maintainers. This isn't a knock on the people who wrote and maintain the libraries, the authors are often doing it entirely on their own time and at their own expense. But as Typescript matures as a full-stack language, so must the libraries that enable its full-stack use.

Strategically, the FOSS fund linked above has different goals than those I envision: I'm asking for an initiative centered around full-stack Typescript specifically. I don't know what exactly that looks like. It may not involve you personally or even the core Typescript team, but Microsoft as a company has the credibility and experience to lead the way here. It may be that Microsoft assumes ownership of development and maintenance for certain high-use libraries. Or it could be a little more detached: some Microsoft-backed FOSS organization specifically for the full-stack Typescript ecosystem. Maybe it's as simple as leading by example and forming a pool of companies who use full-stack Typescript to contribute to the costs of development and maintenance.

Whatever it is, I think we can make the case that it benefits Microsoft as much as it does the rest of us. If Microsoft has any stake in people using Typescript, surely the company carries stake in stable, well-documented, well-maintained libraries that enable its use. And more than that, it benefits Typescript as a language: we love Typescript and we want to use it across the stack!

And again, to reiterate @RyanCavanaugh, we're not asking you or the rest of the core TS team to do double duty in your free time or even bake this into your day jobs. Instead, I'm asking that you bubble these ideas up to the powers that be inside the Microsoft organization. We think if they are listening and they act on it, everyone wins.

[BrunnerLivio]

I've promoted this issue in the NestJS Discord Server (8.2k members) in the hopes of enthusiastic Nest community members to pick this up and contribute. Most of the NestJS team members, including myself are unfortunately quite occupied with our day-to-day jobs on top of maintaining the framework. At least from my part, I won't be able to commit to a role, unfortunately.

I think it would be a great to bring a closer community together. NestJS has switched from Gitter to Discord as well and it helped us a lot to boost our community and leverage intrinsically motivated people. I'd be happy to promote whatever chat you want to use as well in our Discord. We have a #partners channel where we try to promote other communities related to Nest.

[rubiin]

I would love to help.

[NoNameProvided]

Hi all! 👋

Super happy to see this issue. Thanks, @jotamorais for opening this. Indeed there is a lot of things to do here but first, we should decide what to focus on. For example, I believe some of the repos and some of the functionality of the popular packages should be deprecated/removed, so we can focus on those functionalities everyone uses.

Which projects to focus on

When deciding what we should focus on we should take into account the weekly download stats for our repos:

| Package | Weekly Downloads |
|----------------------|------------------|
| class-transformer | 321,538 |
| class-validator | 420,852 |
| routing-controllers | 24,307 |
| typedi | 54,138 |
| class-sanitizer | 2,660 |
| socket-controllers | 164 |
| microframework | 23 |
| one | not published |
| model-controllers | not published |
| typestack | not published |

Based on these download counts my take-away is the following:

__class-transformer, class-validator__
It's clearly visible that class-transformer and class-validator are the most popular packages in the organization (mostly thanks to being the default package used in NestJS). So we should give our biggest effort to these two packages. Both require tooling updates, documentation rework, fixes, and API surface rethink. Also, both of them suffer from "feature creep" effect currently. With these two packages, we should also focus on providing a clear way of using them together and separating the responsibilities of both packages.

__routing-controllers__
It's a unique package (aka no other package on NPM provides the same, the closest would be NestJS which uses a very different approach for building APIs following the Angular style approach of having one well promoted and well-documented way of building applications.) We should focus on this project too. Initially, I would focus on fixing bugs and increasing the synergy with the underlying packages (class-transformer, class-validator). However, in the long-term, we should plan a full revamp with the next iteration of features.

__typedi__
Small package, mostly well-defined functionality. After some tooling updates, I don't think it needs much attention besides bug fixes. However, sadly I think "feature creep" started to appear in it too so it would be good to rethink some additions.

__class-sanitizer__
Despite the higher download counts, I would put this package in maintain mode or even archive it (after discussing this with Umed). My reasoning for this:

• the last commit was in 2017
• zero activity from users so the download count is probably a few bigger user with CI
• a weird mix of _class-validator_ and _class-transfomer_ with some extra decorators for stripping
• on NPM it has 3 dependent packages all with zero download count

__socker-controllers__
I would put this package in maintain mode as well (hopefully @rustamwin doesn't mind focusing his main work in other projects) My reasoning for this:

• this project currently provides a small subset of tools required for creating a production app with socket support (eg: no auth)
• it's "just" a wrapper around Socket.IO with not that much-added functionality
• (personal opinion:) while the decorator usage perfectly fits my mental model with entities and defining routes in an API, for sockets you usually take a different approach and adding classes with decorators for handling messages is not scalable in my opinion

__microframework__
No usage. I would sunset it after discussing it with Umed

__one, model-controllers, typestack__
None of the above has published versions and they seem to be just skeletons for projects which Umed never had the time to work on. After discussing with him I would altogether remove these repositories.

What tasks to focus on for next period

I think first we should bring all the repos we want to work on into this century with updated tooling. For me this includes:

• code formatting with prettier (format specified and same across projects)
• linting with eslint (rules specified and same across projects)
• testing with Jest
• automatic dependency update via Dependabot (or renovate)
• CI via Github actions (I can provide a template for this)
• tracking test coverage (I can provide a template for this)
• shared labels across projects (I can provide a template for this)
• automatic release when a contributor creates a release (I can provide the tooling for this)

Note: Introducing prettier is a tricky question. Anno I wanted to do it, but adding prettier will immediately render all pending PR useless due to merge conflicts.

Besides tooling we should focus on:

• documenting the code (code docs are sparse)
• moving documentation into /docs folder and reworking it where needed (a 10 km long README is not a good place for it)
• cleaning up issues
• include synergies between projects (eg class-transformer and class-validator)

The other required and concrete steps we can discuss on every project in the linked issues.

Handling feature creep

Feature creep is a problem in the current projects, and we need to work actively to fix it and prevent it from happening again.

_Feature creep (sometimes known as requirements creep or scope creep) is a tendency for product or project requirements to increase during development beyond those originally foreseen._

Without a doubt, the hardest part of being a contributor is to know when and how to say no to new feature requests. We should define the goal of every project and only accept features that fit that vision.

If left unhandled __it will become a big problem__ and can ruin any project. (Once you add something you cannot just remove it and drowning in deprecated features is not a good thing to do.)

Long-term goals

After fixing and getting up to speed with the projects I would love to have brainstorming about routing-controllers and plan the next iteration of features that will make it into the next level. Some of the topics include auth rethink, typed contexts, built-in API versioning, built-in API documentation, more sane default settings.

As a maintainer what we should focus on

Hopefully, as we will have multiple new contributors I wanted to write a few words about what I believe the most important parts of contributing to a repo are.

• first, the most important thing is answering questions. You cannot help more than with a well-answered question. It's a big part of the job to show users there feature request is not needed because you can make it work with the current toolset of the project.
• the next step is fixing verified bugs. Squashing those pesky litter buggers will make everyone's life easier.
• maintaining code quality, speeding things up is always welcomed
• adding new features is the "last resort" when it's clear that the problem cannot be solved with the current toolset and the requested feature fits the vision of the project

Becoming a contributor

If you have the desire to become a contributor to any of the projects. Please comment on your handle and what projects you want to help in.

Also, we have a newly made Slack at typestack.slack.com. I will try to set up an auto-invite and post an update here.

Edit: It seems I cannot set up auto-invite, because all the existing solutions use legacy tokens which cannot be created anymore. So if anyone wants to join, message me at typestack-slack-invite[???]outlook.com

[lucasmonstro]

I can help in class-sanitizer or another one :)

[ytetsuro]

I can help class-validator.

[serchtul]

I also can help with class-validator 😃

[NoNameProvided]

Just status update: We have updated the tooling in class-transformer, after finalizing the format we will add it to the other repositories and invite the contributors after.

[Kiliandeca]

Hi everyone, I would also like to contribute to class-validator

[NoNameProvided]

Please, everyone who wrote that want to become a contributor, please join our slack via requesting it in the email above and message me on slack after you have registered. Thanks.

[Fl1nn]

hi all, i have proplem with broadcast to update online list, can someone here help me

[NoNameProvided]

Hi all!

I believe everyone has been invited to Slack who posted here. I will go ahead and close this topic for now as we have more than a sufficient number of people who can commit to the repo.

Remember contributions are always welcome! So anyone can help via answering questions, brainstorming ideas that fit into the library scopes, and sending PRs for bugfixes.

[github-actions[bot]]

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.