Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update tsDecorators to use TS 5 transform output #86

Open
ArnaudBarre opened this issue Apr 12, 2023 · 10 comments
Open

Update tsDecorators to use TS 5 transform output #86

ArnaudBarre opened this issue Apr 12, 2023 · 10 comments
Assignees

Comments

@ArnaudBarre
Copy link
Member

ArnaudBarre commented Apr 12, 2023

Requires evanw/esbuild#104

@ProTip
Copy link

ProTip commented Aug 30, 2023

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
Copy link

ProTip commented Apr 29, 2024

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

@ProTip
Copy link

ProTip commented Apr 29, 2024

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
Copy link
Member Author

ArnaudBarre commented Apr 29, 2024

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
Copy link

morajabi commented May 8, 2024

update: it's shipped in esbuild

@ArnaudBarre
Copy link
Member Author

ArnaudBarre commented May 10, 2024

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

@vaynevayne
Copy link

vaynevayne commented Jun 19, 2024

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
Copy link

ProTip commented Jun 20, 2024

@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
Copy link
Member Author

@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
Copy link

thanks You made it very clear

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants