Closed stevefan1999-personal closed 5 months ago
The embed macro itself is compatible with TypeScriptLoader and I the types are correctly stripped, so while I'm not sure what is going on, I would consider this as feature complete
I would interested to revive this PR, does SWC pull many dependencies?
Right now we are trying to use JSDoc types but it is not super.
I am also considering Flow
typing with a stripper in quickjs but typescript is more widely known.
I am opposed to merging this PR. I think adding typescript support is outside of the scope of this library. SWC is a rather large dependencies with loads of options and settings which, if we were to implement this, would have to support configuring.
Personally I see rquickjs as a relatively lightweight wrapper around QuickJS with some tools to make rust integration easier. I don't think rquickjs should ship major additions to QuickJS its feature set.
I think instead rquickjs should have an API which will allow you to add support for typescript if you require it you will have to implement it yourself or maybe use a third party library.
Closing this PR as there seems to be no more comments on my previous justification for not merging this PR.
Do you plan to add a loader trait like was discussed so we can plug another loader in a third party crate?
I must have missed that discussion, there is currently a loader trait in the crate for implementing custom loaders. Is that one insufficient?
This will pull in SWC, the Speedy Web Compiler, to compile both TypeScript and JavaScript and "downpile" it from ES2022 to ES2020 (which QuickJS is last known to support)
SWC is written in Rust, so it is quite easy to integrate and the transpiling overhead is negligible at best. You can see the benchmarks here: Benchmarks – SWC
However there is still some issue. SWC will strip "bare imports" that was not used during hoisting analysis and will have unexpected results if you have not used the reference.
That means something like this:
Will unfortunately be transpiled to this:
However, contrary to most people's understanding this is the ES standard compilant behavior. But most people would expect the module to be loaded and to be honest I don't blame them as I usually got the same kind of issue too.
Another problem right now is that I cannot run this in macro...
Yikes. So right now I can't test it for
#[embed]
some reason.I tried compiling it using stable but it seems like SWC is using
box_pattern
(box_patterns - The Rust Unstable Book (rust-lang.org)), so while this is sorted out (they claimed it is sorted out in Support stable rustc (again) · Issue #7039 · swc-project/swc (github.com) -- spoiler alert: they don't) I would say using SWC implies the need of at leastunstable
compiler as well.