Repository navigation
Sharp notation do not allow decorator ..ย #50602
Description
Activity
You forgot to provide a valid playground link and a self-sufficient code example.
Sharp notation method decorator
Private fields/methods/accessors don't support decorators, because the current implementation of decorators in TypeScript is based on a very old version of the decorators proposal, that old proposal doesn't really integrate properly with private fields.
The current decorators proposal actually has implementers support, and does support private fields/methods/accessors. There's currently an effort to support the current proposal in typescript. However do note that old decorators can't be used in the new decorators proposal, so any such decorators would need be rewritten for the new proposal.
Reacted by Martin JohnsHere's an example for posterity: Playground Link
Decorators as they exist now (we implemented an old spec and are stuck with it) don't work on private fields. I don't think this is something we're going to support. If we don't downlevel the private field to the
WeakMapimplementation, there's no way that we could put our experimental decorators on it. I don't think we'd go and allow our old-style decorators if-and-only-if your target is old enough to not emit private fields directly.There is #49705, which does support
--experimentalDecoratorson accessors, which is different and possible, as the PR shows. Once the new, revised decorators spec is ratified, then we'll have a clear path.Reacted by Martin Johnsunderstood, thank you very much for the detailed answer, I was naively thinking that decorator would works ootb on private method.
A pity really as it limits the decorator usefulness a lot from my perspective.
By the way, it sounds lie it is working when using a // ts-ignore, ofc it s probably kind of a luck and it works too on private method.
So now I am looking for a way to ignore the TS1206 - decorator not allowed here in tsconfig.json, is there a way to obtain this ? so I can use the feature that is not supposed to work ( lucky me) without having to add so many ts-ignore ? - finger crossed
If it's working, that's a fluke; my playground link above shows that the decorators are not applied to the method named with a private identifier, even when we downlevel it into a WeakMap. If you have it working, I'm curious, but
// @ts-ignoreis definitely a bad idea.If it's working, that's a fluke; my playground link above shows that the decorators are not applied to the method named with a private identifier, even when we downlevel it into a WeakMap. If you have it working, I'm curious, but
// @ts-ignoreis definitely a bad idea.I agree it is a bad idea and probably not going to work for ever, actually it is not even working on stackblitz, which make me considering to not use the sharp notation at all anymore, a pity I liked it, I will be back to the old school _ prefix I guess.
https://stackblitz.com/edit/angular-u9s5bb?file=src%2Fapp%2Fbutton-toggle-overview-example.html
In the man time is there a better way to replace the decorator on a private sharp notation use method in 2022 ? maybe by coding a particular proxy on the class itself. The pb is that I use those decorator to provide extremely useful logging capability so I need it for each of the method in the code, it is not just for one or a few of the private methods.
Making those method public would solve the issue, but I believe it is even worse than using the 'fluke' of it working on the private methods.
All ears to find a proper/better solution :)
At least my choie is easy now I will remove the sharp notation and then no need for the ts-ignore anymore, it will be cleaner, pity for the sharp notationthat I liked, maybe I could try to find a ts-lint the enforce the '_' private method pre fixing to keep it in some way.
Agreed, do you have any idea of the timeline ? even years will not make me scared or cry do not worry ;-) just to have an idea, I was not following much the typescript evolutions until now as it was always fitting my needs until that edge case
Raphael (@anymos) Decorator support is part of the
4.9 iteration plan, so likely in November. #50457According to Jake it's likely part of 5.0, so probably in February.
Not in November, no: #50457 (comment)
Probably 5.0.
Reacted by Martin JohnsCool thank you for the feedback, with some buffer, I believe in May it shall be possible, I will review around that time, thank you guys !
Bug Report
๐ Search Terms
Sharp notation method decorator
๐ Version & Regression Information
Trying to use decorators
โฏ Playground Link
Playground link with relevant code
๐ป Code
Decorator (@decorator)()
#method
๐ Actual behavior
TS1206: Decorators are not valid here
๐ Expected behavior
Decorators shall works