RFC-017: Code splitting + Bundle splitting

[hyf0]

• Feature Name: Code splitting + Bundle splitting
• Start Date: 2022/08/25
• Rspack Issue: Nope

Summary

• Make the code splitting feature in RSpack align with webpack
• Implement the feature bundle splitting

Motivation

• Adjust the output of the bundler to fit the real-world demands.

• See the post to see the real-world use case.

Guide-level explanation

• The must feature we need
• One of the reasons why we are making RSpack instead of using Esbuild
• Intruductions of code splitting and bundle splitting
  • https://survivejs.com/webpack/building/code-splitting/
  • https://survivejs.com/webpack/building/bundle-splitting/

How to use

module.exports = {
  ...,
  splitChunks: {
    chunks: 'async',
     minSize: 20000,
      minRemainingSize: 0,
      minChunks: 1,
      maxAsyncRequests: 30,
      maxInitialRequests: 30,
      enforceSizeThreshold: 50000,
    cacheGroup: {
      defaultVendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          reuseExistingChunk: true,
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
    },
  },
  ...,
}

Reference-level explanation

This is the technical portion of the RFC. Explain the design in sufficient detail that:

• Its interaction with other features is clear.
• It is reasonably clear how the feature would be implemented.
• Corner cases are dissected by example.

The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.

The first stage - porting data structures

• Webpack's data structures is based on object oriented programming, so there are a lot of circle references between objects.
  • In other words, the "references" means that the objects own each other.
• There are two ways to porting data structures in Webpack
  • One way, we use Arc<Mutex<T>> to simulate the behaviors, which is the objects own each other.
    • Pros
      • Easy for porting
    • Cons
      • Possibility for casuing memory leak
      • Possibility for casuing dead lock
      • No guarantee for compiler
      • Poor performance with Arc and Mutex
  • The other way, we separate the representation and the storage for data. We will assign ever object a unique id to represent themselves and store the data in the other place.
    • The references between data will be made with id instead of the actual object.
    • Pros
      • Compiler guarantee for
        • No possibility for casuing memory leak
        • No possibility for casuing dead lock
      • No lock
    • Cons
      • More boilerplate code for passing the storage of data
    • In most case, the place for storing data will be Compilation .

Rid

static NEXT_RES_ID: AtomicUsize = AtomicUsize::new(0);

/// Rid stands for Resource Id
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)]
pub struct Rid(usize, Option<&'static str>);

impl Rid {
  pub fn new() -> Self {
    Self(NEXT_RES_ID.fetch_add(1, Ordering::SeqCst), None)
  }

  pub fn with_debug_info(info: &'static str) -> Self {
    Self(NEXT_RES_ID.fetch_add(1, Ordering::SeqCst), Some(info))
  }
}

• Rid stand for Resource Id. I'm open to a better name.
• Rid is a new type for usize.
• Rid is the unique id we are going to assign to objects.

The scond stage - porting code splitting

In this stage, we will

• Align the data structures about code splitting with Webpack
  • Supports ChunkGroup and Entrypoint

The third stage - implment basic bundle spliiting

• Implement the basic bundle spliiting in RSpack
  • Run through the process to see whether there are choke points
  • Supports the most popular bundle splitting features

The four stage - align with Webpack

• Implement all the bundle splitting features in RSpack

Drawbacks

Nope

Rationale and alternatives

Runtime rendering

• Since a chunk will be split to many chunks, rendering runtime need to know the relationships

Prior art

Webpack

A chinese article for studying code splitting and bundle splitting in Webpack

• Code splitting
• Bundle splitting

Swcpack

Swcpack supports name feature of bundle splitting

The implementation is different to webpack.

• No abstraction about ChunkGroup
• Code splitting and bundle splitting is mixed up, so it's hard to see which chunk is created for code splitting or bundle splitting.

IMO, the current implementation of Swcpack is hard to port the bundle splitting features in Webpack

Unresolved questions

• Nope

Future possibilities

Nope