advancedChunks weird splitting

[Micnubinub]

Describe the bug

I think there is something wrong with advancedChunks. I have so many small mapbox chunks, then 1 big 1 over the size limit?

Reproduction

not sure if reproducable without whole codebase

Steps to reproduce

vite build with this config:

import { resolve } from 'node:path';
import tailwindcss from '@tailwindcss/vite';
import react from '@vitejs/plugin-react-oxc';
import { visualizer } from 'rollup-plugin-visualizer';
import { defineConfig, loadEnv } from 'vite';
const CORE = /sentry|zustand|vite|mui|src/app/;

export default defineConfig(({ mode }) => {
process.env = { ...process.env, ...loadEnv(mode, process.cwd()) };
return {

	define: {
		global: 'globalThis',
		_global: '{}'
	},
	resolve: {
		alias: [{ find: '@', replacement: resolve(__dirname, './src/') }]
	},
	server: {
		port: 9100,
		open: true
	},
	base: './',
	build: {
		assetsDir: '.',
		commonjsOptions: {
			transformMixedEsModules: true
		},
		reportCompressedSize: false,
		cssCodeSplit: true,
		emptyOutDir: true,
		rollupOptions: {
			treeshake: true,
			output: {
				assetFileNames: (assetInfo) => {
					if (assetInfo.names.some((name) => name.includes('favicon')))
						return '[name].[ext]';
					return '[name]-[hash].[ext]';
				},
				advancedChunks: {
					maxSize: 1_000,
					minSize: 500,
					groups: [
						{
							maxSize,
							name: 'mapbox',
							test: (id) =>
								id.toLowerCase().includes('mapbox') && !CORE.test(id)
						},
						{
							name: 'pdf',
							test: (id) => id.toLowerCase().includes('pdf') && !CORE.test(id)
						},
						{
							name: 'konva',
							test: (id) =>
								id.toLowerCase().includes('konva') && !CORE.test(id)
						}
					]
				}
			},
			cache: false
		},
		minify: true,
		outDir: '../dist/web/',
		sourcemap: true
	},
	plugins: [
		tailwindcss({
			minify: true
		}),
		react(),
		process.env.GITHUB_ACTIONS
			? undefined
			: visualizer({
					open: false, // TODO check sizes
					filename: 'tmpStats.html'
				})
	]
};

});

System Info

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 1.79 GB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.2.0 - /opt/homebrew/bin/node
    Yarn: 1.22.22 - /opt/homebrew/bin/yarn
    npm: 8.19.2 - /usr/local/bin/npm
    bun: 1.2.15 - /opt/homebrew/bin/bun

Used Package Manager

bun

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs and the Rolldown-related guide.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

I guess your input has a module that is large. Which mapbox package are you using?

[Micnubinub]

@sapphi-red I think at the time it was mapbox-gl 3.13.0

[sapphi-red]

The mapbox-gl.js file in mapbox-gl is 1.5MB. That is probably the reason.
I wrote the reason why this happens in rolldown/rolldown#5014. For now, this is an expected behavior.

[Micnubinub]

@sapphi-red isn't it really weird that it's generating ~30 sub 100kb files? Plus it's destroying the whole point of a bundler. Now to load a page with a map it needs create a connection to download all those files

[hyf0]

isn't it really weird that it's generating ~30 sub 100kb files?

It creates that much files due to the configuration. Your test catch modules that way bigger than 1_000 size, rolldown would have to create more chunks to satisfy the size limitation which is created chunks should be smaller than 1_000.

To improve the situation, here's my notes:

• Set proper maxSize and use test to catch sensible modules.
• Sizes are caclucated based on module's original size. It might have some gap comapred to the bundled size, especially when minifer got enabled.
• Siince mapbox-gl.js itself is a huge js file, it's better to split itself into a separate chunk alone to gain better cache invalidattion rate.