question: Is this project dead?

[martin-homer]

It has been almost a year and a half since the latest release. There are a bunch of outdated dependencies.

Should we migrate away from routing-controllers? any alternative?

Thanks

[FrancisBehnen]

There's an active issue here: https://github.com/typestack/routing-controllers/issues/783. You could switch to the PR that solves the deps for the time being

[pezholio]

@node-decorators/express looks like a good alternative. Not quite as full-featured, but something to build on for sure

[aviranco]

@martin-homer Ist he outdated dependencies resulting an issue?

Its a great lightweight library thats too bad there are no recent updates, however it seems it did achieved its goal making a lean decorator-based version of express, with validations etc.

Is there a concrete feature/bug that you are looking forward to?

There is NestJS which also offers using controllers with Decorators however it is a whole framework that offers a comprehensive solution (much more heavy compared to routing-controllers, therefore can be an overkill).

@pezholio Seems very similar, however I noticed it is not maintained for more than a year and way behind routing-controllers so I would suggest better skipping this one.

[ghost]

@aviranco yes, this is an issue for us because of outdated dependencies with known vulnerabilities.

We have other dependencies that also use class-validator but we can't update to newer versions (conflicts). As far as our usage, this routing-controllers feature complete and we wouldn't like to switch to other alternatives.

NestJS is what inspired us to choose routing-controllers but migrating to it is a larger effort.

[teddybee]

Is there any possibility to use/define a custom validator?

[mlois-efimob]

Really seems dead, lots of security problems with peer dependencies that are not updated, :(

[borjapazr]

Although this seems to me a great project, I have migrated to Ts.ED and so far it seems to me a great lightweight alternative.

[leonardlin]

Can someone recommend one that would have the lowest migration effort / most similar annotations?

[borjapazr]

Can someone recommend one that would have the lowest migration effort / most similar annotations?

I recently migrated routing-controllers to Ts.ED in a template I developed. Here I summarize my experience, but in summary, it was inexpensive and I gained a lot from the change.

[spicemc]

Can someone recommend one that would have the lowest migration effort / most similar annotations?

I created a fork with updated dependencies. Issues like #783 is fixed. It's published as routing-controllers-extended and is ready to use. The migration effort is very low.

[leonardlin]

Can someone recommend one that would have the lowest migration effort / most similar annotations?

I created a fork with updated dependencies. Issues like #783 is fixed. It's published as routing-controllers-extended and is ready to use. The migration effort is very low.

uiii! can't wait to try, thanks so much

[sentientmachin3]

Am I the only one thinking TsEd is a bit too much? I mean, looks great but it feels overengineered. I will move to the fork.

[borjapazr]

Am I the only one thinking TsEd is a bit too much? I mean, looks great but it feels overengineered. I will move to the fork.

I thought the same as you, but I did the migration to Ts.ED and it is very simple and does not add too much complexity.

Here you can find a template for creating a production-ready REST API using Ts.ED.

[air2]

Same here, also moved to tsed. Just do not forget to implement the class-validator middleware as provided in the sample. I think if there is a fork, that is much easier. It was quite some work to understand all the differences between the projects. I needed to switch from esbuild to swc to get tsed working on an acceptable compilation speed for debugging. Also i needed to implement some custom decorator to minic the ip address decorator from this project and to get the current user i needed to modify the authenicator middleware. That said, tsed is a very nice project, with lots of possibilities. Verstuurd vanaf mijn iPhoneOp 19 nov. 2022 om 15:15 heeft Borja Paz Rodríguez @.***> het volgende geschreven:

Am I the only one thinking TsEd is a bit too much? I mean, looks great but it feels overengineered. I will move to the fork.

I thought the same as you, but I did the migration to Ts.ED and it is very simple and does not add too much complexity. Here you can find a template for creating a production-ready REST API using Ts.ED.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

[borjapazr]

Same here, also moved to tsed. Just do not forget to implement the class-validator middleware as provided in the sample. I think if there is a fork, that is much easier. It was quite some work to understand all the differences between the projects. I needed to switch from esbuild to swc to get tsed working on an acceptable compilation speed for debugging. Also i needed to implement some custom decorator to minic the ip address decorator from this project and to get the current user i needed to modify the authenicator middleware. That said, tsed is a very nice project, with lots of possibilities. Verstuurd vanaf mijn iPhoneOp 19 nov. 2022 om 15:15 heeft Borja Paz Rodríguez @.***> het volgende geschreven:

Am I the only one thinking TsEd is a bit too much? I mean, looks great but it feels overengineered. I will move to the fork.

I thought the same as you, but I did the migration to Ts.ED and it is very simple and does not add too much complexity. Here you can find a template for creating a production-ready REST API using Ts.ED.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

What do you mean don't forget to implement the class-validator middleware? By default Ts.ED uses AJV to perform automatic validation. But you can use class-validator if you want.

[leonardlin]

Can someone recommend one that would have the lowest migration effort / most similar annotations?

I created a fork with updated dependencies. Issues like #783 is fixed. It's published as routing-controllers-extended and is ready to use. The migration effort is very low.

routing-controllers-openapi has been migrated to routing-controllers-extended too.

https://www.npmjs.com/package/routing-controllers-extended-openapi

[attilaorosz]

No, the project is not dead. It just needs a little love. I know it was a bit miscommunicated but here's a thread from NoNameProvided: https://github.com/typestack/class-validator/issues/1775 or https://github.com/typestack/typedi/issues/391

@spicemc Would you consider creating a PR from your fork? There are some additional enhancements that need to imlpemented but the release cycles should be smoother from now on. (Hopefully)

[spicemc]

@spicemc Would you consider creating a PR from your fork? There are some additional enhancements that need to imlpemented but the release cycles should be smoother from now on. (Hopefully)

Sure, i'll create a PR.

[ghost]

No, the project is not dead. It just needs a little love. I know it was a bit miscommunicated but here's a thread from NoNameProvided: typestack/class-validator#1775 or typestack/typedi#391

@spicemc Would you consider creating a PR from your fork? There are some additional enhancements that need to imlpemented but the release cycles should be smoother from now on. (Hopefully)

thanks @attilaorosz ! Closing this one

[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.