Breaking change: disabling default transformation and deprecating internal types

[h-a-n-a]

Rspack future: disableTransformByDefault

Summary

This change aims to deprecate two internal features in 0.4.0:

• Default transformation
• Native internal types

Multiple PRs will be submitted, users of Rspack can opt-in these features by enabling corresponding
experiments.rspackFuture options.

Motivation

The idea behind this is to provide a better alignment and design concept with webpack.

Disabling default transformation

Webpack is plug-able with its outstanding plugin system and highly resource manipulative
with it's loader infrastructure, giving that the bundler itself a web standard bundler. So,
for the bundler itself, it does not trying to do any internal code transformation related to something
like es2022 -> es5 transformation from the perspective of user code. This means that everything
can be opt-in progressively and keep the main bundler pipeline as clean as possible in spite of
modifying the module format itself for cross-platform reason since different platform requires different
module linking strategy(just like things how every linker is doing).

Here's how webpack bundles JS files:

However, here's how rspack deals with JS files:

It looks the same right? However there's a gap in the internal parsing stage between webpack and rspack.
If developers were to compile the application to elder JavaScript syntax, in webpack, they have to configure a
loader to do so, giving that option.target is only an option to control the generated webpack runtime not the
code input by user, however, in rspack, users only need to configure the option.target to achieve this.

Why that's a difference and at what cost does this feature take? The essential concept of rspack is to make the bundler
itself as fast as possible. However, configuring loaders such as babel-loader greatly jeopardizes performance.
After a discussion within the team, we discuss to leverage the option target to handle the syntax downgrading
with regard of the fact that we don't have anything to replace babel-loader at that time. By doing so, we lost
the control of features like Rule.include and Rule.exclude, etc provided by Webpack. Does that hurt? Definitely!
In the world of web application bundling, we would like to treat different files with different resource processing logic.
Often, we regard files in the node_modules as downgraded modules. We don't want them being added to a transforming
pipeline again as these tasks are CPU intensive and not to say there's some cases we should not do any transformation
at all, for example: core-js transformation and we have to manually
exclude the transformation for these polyfill libraries. These logic all located at the internal parser, making Rspack main
pipeline a real mess. However, we don't have a choice at that time.

This code can be deprecated once builtin:swc-loader is landed. We can finally remove these thing at once:

Removing internal types

Webpack does not provides internal Rule.types like ts, tsx, etc. In order to make webpack team and us on the same
page, we would like to remove all these internal types and try to come up with a new solution for that.

Guide-level explanation

Only transform web standard modules

JavaScript-like files with non-webstandard features will result in a parse error:

• decorator
• export default from

TypeScript-like files will convert decorators with as if experimentalDecorators and emitDecoratorMetadata are turned on(as what it is in the old version).

Make options.target for runtime only

options.target is only regarded as an option to control Rspack's runtime downgrading.
After this change, this behavior is aligned with webpack.

before:

// rspack.config.js
module.exports = {
  // other configurations
  target: ["web", "es5"],
  builtins: {
     presetEnv: {
         targets: ["Chrome >= 48"]
     }
  }
}

After:

module.exports = {
    // other configurations
  target: ["web", "es5"], // only for runtime transformation
  module: {
     rules: [
       {
           test: /\.js$/,
           loader: "builtin:swc-loader",
           options: {
              sourceMap: true,
              jsc: {
		parser: {
		  syntax: "ecmascript"
		}
	      },
              env: { 
                 targets: "Chrome >= 48"
              }
           }
       }
     ]
  }
}

Additional Rule.type will be deprecated

Additional Rule.type will be deprecated in v0.4.0. We are working with the webpack team to
add the same functionality back as soon as possible, hoping to give you an out-of-the-box
support to some widely-used features. But for now, these types will be deprecated.

• typescript-like: ts, tsx, typescript
• jsx-like: jsx, jsx/auto, jsx/esm, jsx/dynamic.

before:

// rspack.config.js
module.exports = {
  // other configurations...
}

After:

module.exports = {
   // other configurations
  module: {
     rules: [
       {
           test: /\.ts$/,
           loader: "builtin:swc-loader",
           options: {
              sourceMap: true,
              jsc: {
		parser: {
		  syntax: "typescript"
		}
	      }
           },
          type: "javascript/auto"
       }
     ]
  }
}

[hardfist]

we may need some performance stats about the before and after

[h-a-n-a]

Check out this #4367