RFC-019: more target environments support

[jerrykingxyz]

• Feature Name: rspack_target_config
• Start Date: 2022/09/01
• Rspack Issue: how to expose some swc compile configuration  #635

Summary

let rspack support to compile for multiple environments, such as web, webworker, es5, browserslist and more

Motivation

even we support most features out of the box in rspack, but we still need to some swc compile configuration for custom result.
for example

• legacy browser support: need configuration for browserlist、polyfill
• react runtime: custom jsx factory support、css in js support、automatic jsx runtime support
• minify: minify options
  etc...

Guide-level explanation

target config

like webpack target, we need to support more type of target

{
  ...
  target: string | string[] | false
}

• string
  • web - Compile for usage in a browser-like environment (default)
  • webworker - Compile as WebWorker
  • esX - Compile for specified ECMAScript version
  • browserslist - Infer a platform and the ES-features from a browserslist-config (if browserslist config is available)
    • env.targets in swc config
    • .browserslistrc
    • browserslist field in package.json
• string[]
  When multiple targets are passed, then common subset of features will be used
• false
  Set target to false if none of the predefined targets from the list above meet your needs, no plugins will be applied.

swc config

even though the target above can control ouput result, we still need to some swc compile configuration for custom result. we can wrap and expose some swc param in builtins

{
  builtins: {
    // default true
    polyfill: boolean
    // production mode default true, development mode default false
    minify: boolean
  }
}

Reference-level explanation

target config

sequenceDiagram
    participant user
    participant node
    participant node_binding
    participant rspack
    user->>node: userConfig
    Note right of user: { target: string[] | string | false, builtins }
    node->>node_binding: rspackConfig
    Note right of node: { target: string[], builtins }
    node_binding->>rspack: compilerOption
    Note right of node_binding: struct target {  platform,  es_version } & enum 

Loading

swc config

sequenceDiagram
    participant user
    participant node
    participant node_binding
    participant rspack
    user->>node: userConfig
    Note right of user: { builtins: { polyfill, minify } }
    node->>node_binding: rspackConfig
    Note right of node: { builtins: { polyfill, minify, browserslist } }
    Note right of node: browserslist is read from project browserslist config
    node_binding->>rspack: compilerOption
    Note right of node_binding: enum builtins { polyfill, minify, browserslist }

Loading

because of swc does not support reading browserslist config from .browserslistrc & package.json(more info), we will use browserslist to load config in node and pass into builtins.browserslist

The first stage

in this stage, we will

• make rspack & node_binding support target config

The scond stage

in this stage, we will

• make rspack & node_binding support builtins.swc config
• create swc plugin and converge all places where use swc

Drawbacks

Nope

Prior art

Nope

Unresolved questions

Nope

Future possibilities

Nope

[h-a-n-a]

I have a few concerns:

1. Passing the options from swc options as a whole directly may not be suitable for rspack. Since transforming may happen in many steps. Applying plugins like transform-import is more likely to happen in module build, however, minify is used for code generation.
2. For swc plugins
   1. AST compatibility needs to be taken into account. What's the solution for swc and nextjs?
   2. In a previous benchmark for speedy-native, the performance of wasm-based plugins seem not as good as NAPI-RS's not to mention the overhead of introducing a wasm runtime. I think we need a deliberate investigation of the plugin system not only for supporting swc-plugin but also for native plugins for Rspack before jumping into a conclusion.

[jerrykingxyz]

1. yes, i will keep the original configuration value
2. because of performance, i prefer to use NAPI-RS. all about the swc plugin, i will open a new RFC to discuss it