transformer: ecma decorators
https://github.com/tc39/proposal-decorators?tab=readme-ov-file#how-should-i-use-decorators-in-transpilers-today
esbuild: https://github.com/evanw/esbuild/pull/3754 babel: https://babel.dev/docs/babel-plugin-proposal-decorators#versiont tsc: https://devblogs.microsoft.com/typescript/announcing-typescript-5-0/#decorators
The conformance suite we should follow is https://github.com/tc39/test262/pull/4103, it should be ready in a month or two, we should help out and provide feedback to it.
I talked to pzuraq (decorators champion), we agree to defer implementing legacy if possible, but actual real world usage require us to implement legacy decorators first (for rolldown).
EDIT: The legacy decorator and metadata emitter have already been supported for a while.
- https://github.com/oxc-project/oxc/pull/8614
- https://github.com/oxc-project/oxc/pull/9057
Reminder: https://github.com/oxc-project/oxc/issues/8628
- [ ] reenable file https://github.com/oxc-project/monitor-oxc/commit/28c3d1a7eb949e617b94f7fd33dccfc42e24b604
- [ ] add a hard error when stage 3 decorator is encountered.
Any update on supporting Stage 3 decorators (even experimental without accessor support)?
Because I see that legacy decorators are supported, but not Stage 3 which is enabled by default in TypeScript since 5.0 and supported by esbuild, swc, etc.
[!IMPORTANT] We are going to hold off on implementing decorators for now.
Implementing transform for decorators requires a huge amount of work. The spec was updated multiple times since it reached stage 3. The implementation in the engines is still in progress and other changes may be introduced during the process. We currently don't have the bandwidth to catch up with the spec changes, which otherwise would make the ecosystem fragmented.
We will revisit once we are confident that the spec is stable or have a bandwidth to catch up.
See https://github.com/tc39/test262/issues/4042 for the progress on the standard side
Hey @sapphi-red, decorators are quite important to our workflow, and others using esbuild + Rollup. With Rolldown being a drop in replacement for Rollup, I do see this breaking a lot of other projects that may take the drop in as verbatim. I do appreciate that the spec has changed a lot in the last while but do you have a roadmap to support this say in the next ~1, ~2 years?
Hello :3 I'm not related to oxc, but I want to share some informations about this.
I tried to implement this for vite plugin to replace unplugin-swc, and it took 30 iterations of GitHub Copilot. The code is implemented by LLM, and you may not a fan of LLM, but it can be a reference.
The main point I got is this. In oxc mainstream, it seems barely feasible to maintain 800 LoC or more for unstable specification.
https://github.com/nyanrus/vite-oxc-decorator-stage-3/blob/main/decorator-transformer/src/lib.rs#L278 https://github.com/nyanrus/vite-oxc-decorator-stage-3/blob/main/decorator-transformer/src/transformer.rs#L560
It is working and using in my another project, but not verified. please take a look carefully :) Feedback welcome!