Repository navigation
Inaccurate Decorator Status Documentation #60282
Description
Activity
- addeddocIssues and PRs related to Node.js documentation.Issues and PRs related to Node.js documentation.
on Oct 16, 2025 Sure, wanna send a PR?
- addedstrip-typesIssues and PRs related to TypeScript type stripping.Issues and PRs related to TypeScript type stripping.good first issueIssues that are suitable for first-time contributors.Issues that are suitable for first-time contributors.
on Oct 16, 2025 @marco-ippolito Depends what the plan of the team is. Given that decorators don't seem to be currently in development is the Node team going to reconsider their decision to not handle them in transforms? Or is the Node team just giving up on this? I would be disappointed to learn it's the latter since decorators are a pretty widely used feature of TypeScript and the lack of support for them will block many people from relying on the native Node support.
Reacted by Daniel HauptI'm against performing polyfill of whatever kind so I think they will should stay unsupported until shipped in v8. Also legacy decorators differ substantially from the stage 3 proposal so this would create a weird situation when decorators will be finally shipped
Reacted by Jake Bailey, Jacob Smith and Daniel HauptI think that's fine tho -- TypeScript already supports stage 3 decorators, and library authors who have implemented decorators already can use overloading to support every decorator implementation -- so I think it makes sense not worry so much about compatibility with older decorators from a v8 perspective -- it's a library-author responsibility.
I'm against performing polyfill of whatever kind
How does this square with the current experimental transforms?
I'm against performing polyfill of whatever kind
How does this square with the current experimental transforms?
Experimental transforms will always stay behind a flag
I'd be fine if TS decorators also always stayed behind this flag.
I could add a flag to unlock decorators (that implies transform)
@nodejs/typescript wdytReacted by Steven, Jake Bailey, Rob Palmer, Jacob Smith and Geoffrey BoothThis would be a nice medium term solution until the engines natively support decorators.
I don't think this is a good idea, personally. Decorators are not actually in the ratified spec yet, could still change, or even not happen? (I don't have full context on the discussions around this.)
If trying to say "TS decorators", that just begs the question "which decorators?". TS has two options, and you don't know which one to emit unless you read tsconfigs. Most people using decorators aren't using the ECMAScript spec'd ones.
Reacted by Steven and Jacob SmithI would much rather the docs be corrected to not imply that this problem has anything to do with TS, because it really doesn't. (I didn't realize that sentence was in there, actually.)
Decorators are not actually in the ratified spec yet
Stage 3 is ready for final(ish) implementation, ya? Stage 2.7 was feedback from implementation attempts?
TS Decorators
We only need to care about actual spec decorators from TC39, ya?. People coming from TS have "TS Decorators", but if we're adding decorators we don't care about TS' "Stage 2" implementation -- we don't care about tsconfigs.
docs be updated
improved clarity is always a welcome improvement <3 🎉 <3
Reacted by Peter Wagenet9 remaining items
I’d like to contribute to this as a Good First Issue.
I’m thinking of replacing it with:
Since Decorators are currently a TC39 Stage 3 proposal, they are not transformed and will result in a parser error. This is a temporary limitation and will be resolved in the future.
I’d really appreciate any feedback on this, and if it looks good, I’d be happy to take this on.
Id not say its a temporary limitation since engines might never ship. Id say we wont polyfill and they wont be supported until supported natively in the language
Reacted by StevenThanks for the feedback! Does this make sense?
Since Decorators are currently a TC39 Stage 3 proposal,
they are not transformed and will result in a parser error.
Node.js does not provide polyfills for decorators and will not support them until they are supported natively in JavaScript.or
Since Decorators are currently a TC39 Stage 3 proposal,
they are not transformed and will result in a parser error.
Node.js will not polyfill decorators; they will become available once supported natively in JavaScript engines.Reacted by Jacob Smith and Geoffrey BoothYou can go ahead an open the PR 🙂
Reacted by Muhammad Salman Aziz- added a commit that references this issue
on Oct 19, 2025 - added a commit that references this issue
on Oct 23, 2025 - added 2 commits that reference this issue
on Feb 17, 2026
Affected URL(s)
https://nodejs.org/api/typescript.html#typescript-features
Description of the problem
The docs currently read:
However, the PR for this was merged over a year ago and there still seems to have been no action. While I would prefer that Node actually support this, the docs should be updated to not imply that it will be resolved soon.
See also this comment which indicates the lack of motion around decorators.