#10840·rolldown

[Feature Request]: Report bundler timings, not plugin timings only

Author: IWANABETHATGUYCreated Sep 8, 2026Updated Sep 15, 2026

What problem does this feature solve?

checks.pluginTimings already measures the user callbacks on the options. #10508 and #10509 added them, and v1.2.2 shipped them.

Coverage today:

  • codeSplitting.groups[].test / groups[].name (#10508)
  • entryFileNames / chunkFileNames / sourcemapFileNames (#10509)
  • banner / footer / intro / outro / postBanner / postFooter (#10509)
  • external (#10509)
  • globals / paths (#10509)
  • assetFileNames
  • sanitizeFileName

Two more gaps remain.

  1. The report calls every row a plugin hook. The headline says Plugin hooks ran for 4.2s of this 7.1s build (59%). A codeSplitting.groups callback is not a plugin hook. The user then looks for a slow plugin, and there is none.
  2. All groups share one row. The recorder keys a row on the hook name, so codeSplitting groups[].name holds the sum of every group. A user with 5 groups cannot see which group is slow.

What does the proposed API look like?

Rename the concept to bundler timings. The check keeps its behaviour under a new name. The old name stays as a deprecated alias.

javascript
export default {
  checks: {
    bundlerTimings: true, // `pluginTimings` stays as a deprecated alias
  },
}

The report then names each row by its owner, and gives one row per group.

JS callbacks ran for 4.2s of this 7.1s build (59%).
The slowest callbacks, timed inside each callback:
  - output options codeSplitting groups[].name "vendor" (30%, 2.1s, 4000 calls)
  - plugin vite:import-analysis transform (12%, 0.9s, 800 calls)

A group whose name is a function has no label for the report row. Rolldown warns and asks the user to give the group a name. The field that carries the label is open.