RFC: experimental feature workflow

[IWANABETHATGUY]

Background

The goal of Rspack is to create a bundler that is as compatible with webpack as possible. However, in reality, things are often more complicated, and we have to make many configuration adjustments to meet the needs of users, including but not limited to performance and user experience. For example, to provide a better HMR user experience, we choose to use an incremental build algorithm to support HMR (experiments.incrementalRebuild). To progressively refactor the underlying bundle splitting implementation, we introduced experiments.newSplitChunks. There are also some unstable features like experiments.lazyCompilation and experiments.asyncWebAssembly.

Issues and Solutions

Conflict between Rspack experiments and webpack.config.js experiments

Description

Webpack already has a configuration item called experiments, although this configuration item is not commonly used (compared to loader in webpack.config.js, the usage frequency is about 100 times lower). Sharing the same configuration item will confuse users, making it difficult to distinguish which configuration items are compatible with webpack.config.js and which are Rspack's experimental configurations.

// webpack experiments
module.exports = {
    experiments: {
        css: true,
        outputModule: true,
    }
}

Solution

1. Share the experiments field with webpack, but put all Rspack-specific experimental properties into experiments.rspack. For example, the current configuration:

module.exports = {
    experiments: {
        incrementalRebuild: true,
        lazyCompilation: true,
        newSplitChunks: true,
        asyncWebAssembly: true
    }
}

becomes:

module.exports = {
    experiments: {
        // compatible with webpack
        asyncWebAssembly: true,
        rspack: {
            incrementalRebuild: true,
            lazyCompilation: true,
            newSplitChunks: true,
        }
    }
}

2. Use a new field, such as experimental. The original configuration:

module.exports = {
    experiments: {
        incrementalRebuild: true,
        lazyCompilation: true,
        newSplitChunks: true,
        asyncWebAssembly: true
    }
}

becomes:

module.exports = {
    experiments: {
        // compatible with webpack
        asyncWebAssembly: true,
    },
    experimental: {
        incrementalRebuild: true,
        lazyCompilation: true,
        newSplitChunks: true,
    }
}

How to handle stable experimental features

Description

The existence of experimental features is to explore more solutions to improve build performance, including but not limited to build efficiency, artifact size, and DX, without breaking the user experience. All experimental features can be divided into two categories: some features are abandoned because they do not meet user expectations, and some features are stable after long-term experimentation and user satisfaction. In this case, continuing to place the feature in experiments is obviously inappropriate (because experiments implicitly tell users that these features are unstable and should not be used in production).

Solution

If it is a feature in webpack experiments, follow the adjustments of webpack (that require webpack to continue to iterate). If it is an experiments feature in Rspack, continue to iterate it by placing it in builtins.

How to promote experimental features

Description

Experimental features cannot evolve into stable features over time automatically. To become a stable feature, a large number of volunteers are needed to experiment and provide feedback. The following is a simple process for promoting experimental features:

1. Propose an RFC (optional) and implement it.
2. Add a switch for the feature and add relevant configuration in the corresponding experiments. Highlight the feature in each week's release note, preferably with a demo animation or image. Rspack_dev (Twitter) can also expose the feature to encourage more users to experiment with it and collect feedback. The experimental feature should be turned off by default so that even if there are implementation problems, the number of affected users can be minimized.
3. Whenever our experimental feature has some new progress, it can be exposed in various media to encourage more users to experiment and provide feedback.
4. (Optional) After a certain period of time and depending on the situation (after many user experiments and relative stability), the experimental feature will be turned on by default.
5. After extensive user testing and confirming the stability of the feature, move the configuration to builtins. However, do not immediately delete the corresponding configuration item in experiments. You can use util.deprecate to recommend users to use the configuration item in builtins. After a certain version iteration, delete the configuration item in experiments to complete the iteration advancement of the entire experimental feature.

[hyf0]

How about adding experiments.rspack first?

[IWANABETHATGUY]

These solutions are just proposals, feel free to publish your different ideas and opinion

[hyf0]

IMO, I think solution 1 is good enough.

module.exports = {
    experiments: {
        // compatible with webpack
        asyncWebAssembly: true,
        rspack: {
            incrementalRebuild: true,
            lazyCompilation: true,
            newSplitChunks: true,
        }
    }
}