new decorator proposal support

[RoenLie]

Hi!
Are there plans to add support for the upcoming decorator proposals?

[PodaruDragos]

this won't be possible for us, since we use parameter decorators and those parameters decorators are not implemented ( they are stage 1 )

[rsaz]

@RoenLie what decorators are you referring to?

We can ignite this conversation and provide a closing to this topic that aligns with our current library roadmap.

Let us know, @rsaz @notaphplover

[RoenLie]

This would in relation to this proposal: https://github.com/tc39/proposal-decorators
and https://github.com/tc39/proposal-decorator-metadata

It's getting closer and closer to becoming implemented in the browser, and having support for property decorators and class decorators would be a great thing.
Yes the parameter and constructor decorators might not yet be at stage 3. But I believe these features could be marked as incompatible for those who wish to not use "useExperimentalDecorators" whenever the feature hits browsers.

[notaphplover]

Without parameter decorators we cannot keep inject and other parameter decorators support, which are core decorators of the library. Until parameter decorators are not supported we cannot go that way.

[RoenLie]

It's understandable but also a bit sad if there is no middleground while the spec is not fully supported.
It would mean the application I work on either has to fork inversify and perform the changes ourselves, change to a different DI library or create our own.
There are ways of creating dual support for both decorator specs, and in the case where one is not supported using the official proposal, a warning or type error could be emitted.
Doing this would not removed inject from the library, it would just make it so that if using the new decorator signature, those consumers would have to use it on properties and not parameters.
This would also only affect those who purposefully choose to change their typescript options to opt into the new official way.
There are ways through this phase, but cannot do anything but bring up the wish from my side.

[notaphplover]

There are ways of creating dual support for both decorator specs, and in the case where one is not supported using the official proposal, a warning or type error could be emitted.

That would be amazing. The thing is, how would be inject implementation? If experimentalDecorators option is enabled, inject would work. If not, inject should be invoked the same way javascript developers do, relying on Reflect.decorate.

If experimentalDecorators is disabled, there's no way to throw a warning in this scenario since using @inject wouldn't even be syntactically correct. Maybe I'm missing something, could you provide a minimal code example with your inject implementation approach?