RFC: supporting multiple separate bundles in one environment

[sapphi-red]

Motivation

In server-less platforms, it is preferred to minimize the server bundle size to reduce the server start up time. Currently, when multiple entrypoints (input) is specified in a single environment, the output will share the code between all entrypoints. This means a function that is not used by the current entrypoint can be loaded, causing unnecessary parsing / execution.

Proposal

The main change is on the build side. The dev side is changed to align the behavior with the build side.

Build side

Add build.rolldownOptions.output.activeInput option. This option will configure which input would be "active" for that output generation.

For example, assume that there's a following files with the following option.

// vite.config.js
export default {
  build: {
    rolldownOptions: {
      input: ['./src/page1.js', './src/page2.js']
      output: [
        { activeInput: ['./src/page1.js'], dist: 'dist-page1' },
        { activeInput: ['./src/page2.js'], dist: 'dist-page2' }
      ]
    }
  }
}

// src/page1.js
import { foo } from './common.js'

foo()

// src/page2.js
import { bar } from './common.js'

bar()

// src/common.js
export function foo() {
  console.log('foo')
}
export function bar() {
  console.log('bar')
}

The output will for each output generation will be:

// dist-page1/page1.js
function foo() {
  console.log('foo')
}
foo()

// dist-page2/page2.js
function bar() {
  console.log('bar')
}
bar()

You can see that the first output generation does not include any code for page2.js and bar is tree-shaken away. Same for the second output generation, foo is tree-shaken away.

Note that Rolldown calls "Build Hooks" (e.g. transform hook) for each output, which means the hooks will be called much much more times (docs). If we go with this proposal, we should revisit that behavior.

Dev side

Need a way to create multiple module runner instances in the same environment so that we can emulate the "separate state" functionality in production.

One idea is to add environment.createRunnerInstance.

Alternatives

Support codeSplitting: false with multiple entrypoints

This is the way proposed in rollup/rollup#2756 and rolldown/rolldown#3986.
This means the single module would be duplicated and included in multiple chunks.
I personally find this problematic because I assume most plugins would expect a single module to be included once.

Allow multiple bundles to be tied with a single environment

Extend build option to be an array.

This way has an inconsitency in dev and build. In build, there will be multiple module graphs, while in dev, there's a single module graph. The transform hook for each module will be called multiple times in build, while in dev, it will only be called once.

Allow multiple module graphs

The change above (i.e. extend build option to be an array) + the change on dev side for the proposal (i.e. add a way to create multiple module runner instances in the same environment).
I feel this is complicated than needed.