proposal-class-method-parameter-decorators
proposal-class-method-parameter-decorators copied to clipboard
Towards stage 2
Hello,
This is mainly a question/discussion that I wanted to start.
I am one of the maintainers of inversify which is a DI library . A very very common question we get is "when are we switching to vanilla decorators". Since inversify or mostly other DI libraries are all doing parameter decorations using the experimentalDecorators flag, supporting stage 3 decorators would be close to impossible with the same UX.
The question would be, has anything changed in the statements of tc39 or is this still something with low interest ?
NestJS is also a library which heavily uses DI and parameter decorators, and this feature (along with decorator metadata), are needed to support vanilla decorators. It would enable us to use tooling such as esbuild with NestJS.
According to the maintainer kamilmysliwiec:
"I don't think we'll support JS decorators till the metadata support & parameter decorators are implemented"
Here's a couple issues requesting this feature:
- https://github.com/nestjs/nest/issues/9558
- https://github.com/nestjs/nest/issues/11414
Any news on this?
Any update on this? TypeGraphQL is another library that uses parameter decorators. I recently ran into trouble creating my own decorator library using vanilla TS decorators which I couldn't then deploy in a project alongside TypeGraphQL, forcing me to downgrade my library to use the experimentalDecorators implementation
as far as I understand it, the decorators proposal itself which is stage 3 for quite some time is mostly done on v8's side but they don't want to be the first to adopt it. If that isn't a priority this will most likely never happen. See notes here agenda