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 swc-project/swc#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: evanw/esbuild#104 (comment)

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

[remloyal]

How to use decorator syntax in JSX? In Vite 5.3

[ProTip]

I have been patching this for over a year via pnpm:

diff --git a/index.mjs b/index.mjs
index 41e1f9f9230aaa2ba6c9eca7f5256e719848a72b..53c20bc6e4b2fa6a2c31bb37ec4627a7b34ae0e9 100644
--- a/index.mjs
+++ b/index.mjs
@@ -172,7 +172,8 @@ var transformWithOptions = async (id, code, target, options, reactConfig) => {
         experimental: { plugins: options.plugins },
         transform: {
           useDefineForClassFields: true,
-          react: reactConfig
+          react: reactConfig,
+          decoratorVersion: "2022-03"
         }
       }
     });

[stephen-dahl]

I have been patching this for over a year via pnpm:

diff --git a/index.mjs b/index.mjs
index 41e1f9f9230aaa2ba6c9eca7f5256e719848a72b..53c20bc6e4b2fa6a2c31bb37ec4627a7b34ae0e9 100644
--- a/index.mjs
+++ b/index.mjs
@@ -172,7 +172,8 @@ var transformWithOptions = async (id, code, target, options, reactConfig) => {
         experimental: { plugins: options.plugins },
         transform: {
           useDefineForClassFields: true,
-          react: reactConfig
+          react: reactConfig,
+          decoratorVersion: "2022-03"
         }
       }
     });

thanks, had to ask chatgpt how to do that in my npm project and found out that npx patch-package is a thing :)

[NullVoxPopuli]

I just found this -- would be great to have support, as decorators are very nice.

[andeeplus]

While waiting for vite support, I'd like to point out the following answer to another thread as a reference on how to use stage 3 decorators in vite. It is easy to get lost in decorators' issues, I hope this will help somebody.

#85 (comment)

[ArnaudBarre]

@andeeplus if you do just that you will loose HMR. Maybe running both with this one first will works but not guarantee.
The best way to do this for now is to patch the plugin.

Reminder: The future of Vite is OXC and opting into a still not fully standard decorator transform that is not fully complete is not something we plan to support long term and that's why I don't want to make it one flag away or the default for now.

[andeeplus]

@ArnaudBarre Thanks for the tips, I've read in several places about the patch but I'm not really sure on what to patch really. I can see an example above but it's not very clear about what to patch. For instance in my current project I'm not using react and if I'm not wrong the patch above is referred to the swc-react plugin and it basically adds decoratorVersion: "2022-03", that is already included in the config I was using.

In any case I was having weird behaviours with the solution I posted above and checking the test suite in the issue that you post in your latest comment I've realized why: the swc transformation unfortunately is not very accurate.

So I took a more naive approach and for my use case the following is more than enough:

import { defineConfig } from 'vite';

export default defineConfig({
  esbuild: {
    target: 'es2022',
  },
});

Thanks for your time.