search

vitejs / vite-plugin-react-swc

Speed up your Vite dev server with SWC
MIT License
774 stars 49 forks source link

Plain Vanilla JS files are excluded from SWC processing/transforms #182

Closed chrischen closed 5 months ago

chrischen commented 7 months ago

I originally opened the issue here: https://github.com/lingui/swc-plugin/issues/77#issuecomment-1840504440

However it was brought to my attention it's actually this plugin that specifically only runs SWC macros on certain file extensions and excludes plain JS files with extensions .js, .mjs, .cjs, etc.

My argument for including it for plain JS files is that SWC macros cannot be used with plain JS files, when they should be allowed. The normal vite-plugin-react with Babel will transform babel macros for vanilla JS files, but switching to this vite plugin they will not be transformed. The reason I'm using vanilla (.mjs) JS files is because I am using Rescript, and the compiler outputs plain JS files with no types.

Here is the relevant line: https://github.com/vitejs/vite-plugin-react-swc/blob/main/src/index.ts#L206-L217

Here is a sample repo showing the Lingui SWC macro not working: chrischen/js-lingui@88e8e19. The Lingui JS SWC macro specifically has a "js" macro for usage outside of React and in Vanilla JS/TS files. The default behavior of this plugin makes that usage impossible unless it's used in a .ts file.

I believe the solution should be to run even plain JS files through SWC.

ArnaudBarre commented 6 months ago

@yyx990803 what do you think?

@chrischen this is done to avoid running SWC on non user code and keep performance good for already compiled code. In the app land, JS is more a compiler target language than something you should write your source code in.

chrischen commented 6 months ago

I am indeed using plain JS as a compiler target language (of Rescript). I am using an escape hatch to use the JS macro, so the macro code is left as-is in the compiled JS.

Maybe an option to override the parser config or perhaps to include JS files?

My understanding is non-user code is either in memory (in dev mode) or in a separate build output folder for production anyways?

ArnaudBarre commented 6 months ago

@chrischen Thanks for your answer, I've implemented something that should be a good trade off in term of flexibility/maintainability, but given some other team member are off in the coming weeks this will probably not be added before January