Support TC39 decorators (TS 5, esbuild 0.21, Vite 5.3)

[ArnaudBarre]

Update: Support for TC39 decorators has been shipped in esbuild 0.21, included in Vite 5.3. SWC support is still not fully there, see https://github.com/swc-project/swc/pull/8970

As the goal of this plugin was since the beginning to enforce good practice and be transpiler agnostic (OXC is coming 👀), I'm still waiting before adding support to the plugin.

In the meantime, you can easily patch the library if you want to opt-in into the use of an unstable feature

[ProTip]

I'm not sure the referenced issue is going to be closed out however Evan posted this update stating parsing decorators was working: https://github.com/evanw/esbuild/issues/104#issuecomment-1597922979

I have also patched this package with pnpm to supply the decorator version to SWC. Along with using SWC for build, this appears to be working in dev, build, and Vitest.

[ProTip]

I've been using this without issue since posting the prior comment. Any interest in a PR to get this into the plugin?

[ProTip]

Looking into this further, the latest versions of SWC do not require specifying the decorator support version. They have moved to Stage 3 as the default decorator version and have introduced new options to switch back to legacy TS decorators.

So, updating to the latest SWC and adjusting the documentation would be a way forward.

[ArnaudBarre]

I was waiting for a stable lowering of the new spec to ship in esbuild to change the behaviour of the plugin, so that people can use them in dev and don't need to bump to much they prod target. That's good news that SWC changed that, I'll take a look and at least add some documentation

Edit: https://github.com/evanw/decorator-tests was updated 2 days ago, I hope Evan will find a implementation that he is ok to ship to esbuild!

[morajabi]

update: it's shipped in esbuild

[ArnaudBarre]

Yep I saw that, I'll look at a new API for the plugin once 0.21 is shipped by Vite

[vaynevayne]

update: it's shipped in esbuild

Hello, I'm not very clear about what swc is responsible for when esbuild is. swc is similar to babel, so syntax downgrade is swc's responsibility. Why does esbuild also have downgrade operations?

[ProTip]

@vaynevayne I personally use SWC for dev and build, but the default at least a while back was for SWC to only be used for dev and esbuild used for build.

[ArnaudBarre]

@vaynevayne esbuild is both a bundler (aggregating multiple JS files into bigger JS outputs) and a transformer (transforming one TS(X) file into JS, while potentially downgrading if enabled). It can do most of what SWC and Babel do, and this is why this is currently the default transformer used by Vite. But because esbuild doesn't support fast refresh, we need to use either babel or SWC for React plugins.

For me it's better to keep SWC usage only in development and let the default vite build use esbuild. This is why syntax downgrading need to be sync between both. While this can be seen as limiting, I actually find that esbuild do a better job at enforcing spec compliance, which avoid creating technical debt int he future.

[vaynevayne]

thanks You made it very clear