Open mikearnaldi opened 2 years ago
I like the premise, obviously. The question is if this makes sense until SWC plugin v2 comes out, or if that would be a swift upgrade. Also the TS processing will be a bottleneck for the otherwise fast SWC, but I agree that it may still be beneficial for performance, and the integration for nextjs etc is especially a bonus.
Perhaps some of the bottleneck could be alleviated by leveraging a language server that keeps running in the background? Perhaps even one shared between editor and swc, though the editor one by default of course only focusses on open files. In my current workflow with TS compiler running in background in watch mode, I always feel like double work is being done.
Might make sense to wait until v2 comes out if it ever will (there are discussions on keeping v1). As of the point on double work I believe the language server picks up the compiled from the background but I am not 100% sure. The idea is indeed something similar to the language server without the server protocol that can potentially be even parallel for. I don't see the ts compiler as a bottleneck but as the only thing in the pipe that does semantic stuff, an integration with swc should save on double file output, source maps linking etc but ofc it's all theoretical
We could leverage a combination of SWC plugins https://swc.rs/docs/usage/plugins and the LanguageService API to enable direct compilation with SWC.
PROS:
CONS:
processCallExpressionAtLocation
etc