Open Luna-Klatzer opened 2 years ago
This will be a focus for Kipper v0.11
and is likely going to be implemented as described in options 1 and 3. Option 1 will be a priority though to allow for specific compilation targets, and the JS and TS imports will slowly be implemented as Kipper continues to be developed.
Due to Browserify issues this issue will probably not be implemented, as Browser support takes precedence.
Is there an existing proposal for this?
This feature does not exist in the latest version
Proposal
With #208, there are now rough plans to implement a target for JavaScript ES2016, which would likely be implemented using TypeScript.
There is a possible issue with that solution though, considering the time and effort that would be required to support multiple ECMAScript versions, the target would have to stick to a few or maybe even only one target, like for example ES2016. That would likely limit the functionality of Kipper to a single target JS version, which would make development a lot easier, but also usage of Kipper a lot more restricted, as modern features are only slowly supported.
A possible solution to that issue could be using
@swc/core
and@swc/wasm-web
, which are both written in Rust and therefore fully memory-safe and more performant than default JS/TS. These provide, like Babel, support for multiple ECMAScript versions and translations to older versions. This would mean if the Kipper JS target generated ES2020 code, the SWC Compiler could transpile it down to ES2018 or ES2016, depending on what the user wants.This also has the advantage of having very performant compilations, while also sticking to the easily customisable nature of Kipper. That could also be applied to the TypeScript target, where older TypeScript versions and ECMAScript versions could be supported. To that, the user wouldn't have to worry so much about configuring a compiler besides the Kipper compiler, as the SWC Compiler could be integrated as an npm dependency and also bundled in the Browser.
To that, Kipper could even create its own Rust Crate where it implements a basic API using SWC and customise its behaviour to add more Kipper-specific features.
Exact behaviour / changes you want
There are three good solutions to utilise SWC in Kipper:
@swc/core
as an NPM dependency and use@swc/wasm-web
for thekipper-standalone.js
browser bundle. In this case, both packages would be used to transpile the code after the JS or TS target generated it. The best case would be that the targets generate the most modern code possible, like for example rn ES2020 (As that's the most modern version supported by SWC yet) and then the SWC Compiler compiles them down to older versions (ES2015-ES2019).@swc/core
as an NPM dependency and use@swc/wasm-web
for thekipper-standalone.js
browser bundle. In this case, only the TypeScript target actually implements code generation and the SWC Compiler would do all of the work for the JS target. This could potentially improve speed (Maybe 5-10%), but it would completely remove the ability to customise the compilation behaviour and result in a weird structure, where the JS target is barely even there.