RFC: Transpilation

[magic-akari]

Currently, SWC has designed two entrances, one is processed based on the ES version, and the other is processed based on the env target.
Along with this, SWC also exports a translation module for each ES version, which, in my opinion, adds some complexity.

I prefer esbuild's approach, but it can be improved.

two feature sets can be defined, one is the target feature set (referred to as target below), and the other is the current feature set (referred to as current below).
Users write the latest code with features that may not always be supported by the target platform. Therefore we need to transpile it.
In general, the target range will be smaller than the current range.
During the transpilation process, we continually modify the current to make it closer to the target.

This approach avoid some problems and bring several benefits:

1. When transpiling, sometimes we need to only slightly lower the level of a higher-level syntax (rather than too much). There have been cases in SWC where a syntax has been transpiled into another syntax, but the order of processing causing the syntax transpilation to be skipped. In case, we need to know the availability of some syntax, query the current, and make assertions.
2. Some features are interrelated, and classifying them by the ES version leads to a lack of consistency in the context. For example, class features are scattered across several ES versions
3. Whether it's an ES version or an env target, we can always transform it into the target feature set for processing.
4. It is possible to customize the target feature set for special platforms(such as deno or hermes).

[Boshen]

Let me jot down something briefly:

• Bun mentioned "edge bundling" and I think this is something we should be working towards https://github.com/oven-sh/bun/issues/121
• Transpilation is just another term for compiler backend code generation, they compile to target triple (CPU, vendor, operating system), JavaScript transpilation target runtime platforms (browsers, node, deno, bun etc)
• There should be two layers, an ECMAScript-feature-level-layer and a preset layer
  • the ECMAScript-feature-level-layer exposes all feature sets, this layer explicit.
    • this is similar to #[feature] in Rust
  • the above features are grouped in presets, for example chrome v100 or node v16
    • users will select all the target platforms and we compute the common denominator feature set
    • the target platform can be dynamic, e.g. from end user browser strings, to enable edge bundling
    • this is our target-triple
    • this is where most people will interact with

I briefly talked to @magic-akari, and we are going to study how LLVM / Go handles these two layers.

[Boshen]

I did some research today, I plan to port how its written in typescript. #915

[magic-akari]

I did some research today, I plan to port how its written in typescript. #915

In SWC, there will be only one pass for verbatim module syntax if swc-project/swc#7202 get merged.