Summary
This chore updates vite.config.js to implement a manual chunk-splitting strategy for production builds. By separating third-party dependencies (node_modules) into a dedicated vendor bundle, we can minimize the primary application bundle size and optimize browser caching.
Problem
Currently, the project uses the default Vite build configuration, which frequently compiles application code and third-party dependencies into a single, large JavaScript bundle. Following the recent migration to Vite 6, leaving production assets unfragmented leads to larger initial page load sizes, slower time-to-interactive (TTI) performance, and prevents browsers from caching unchanged third-party libraries independently of rapidly changing source files.
Proposed solution
Modify the build configuration inside vite.config.js to utilize Rollup's manualChunks option. This will instruct the bundler to automatically identify imports originating from node_modules and split them off into an independent asset file.
The targeted configuration adjustment under the export statement will look similar to this:
JavaScript
build: {
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes('node_modules')) {
return 'vendor';
}
}
}
}
}
Suggested scope
If you already know the likely implementation area, mention it here:
Suggested files or directories: vite.config.js located in the root directory of the repository.
Related route, page, component, API, or plugin: Build configuration and pipeline settings.
Acceptance criteria
List the minimum requirements for this feature to be considered done:
[ ] Production build configurations partition node_modules code into a unique chunk (e.g., vendor-[hash].js).
[ ] Running a production build compiles cleanly without warnings, syntax errors, or circular dependency breakage.
[ ] The localized dev server environment (npm run dev) remains unaffected and retains its rapid startup speed.
[ ] The bundled production application functions flawlessly in preview mode with zero runtime console regressions.
Test plan
Explain how a contributor or maintainer can verify the feature works.
Run a fresh production build locally using terminal command: npm run build.
Inspect the generated terminal output asset map under the dist/assets/ output.
Verify that a separate vendor asset chunk has been created alongside the standard index chunk.
Launch the local build preview via npm run preview and navigate the application dashboard to confirm that all assets load properly with zero runtime bundle errors.
Alternatives considered
Leaving configuration as default: Rejected because unoptimized chunks delay loading performance, particularly as the project adds more visualization or parsing modules.
Granular chunking per dependency: Rejected for now to prevent creating an excessive amount of small HTTP requests, sticking to a balanced single-vendor chunk approach instead.
Additional context
Optimizing the build architecture is highly beneficial as SecuScan scales up its dependencies under Vite 6. I'd love to implement this optimization—please assign this issue to me under GSSoC 2026!
Summary
This chore updates vite.config.js to implement a manual chunk-splitting strategy for production builds. By separating third-party dependencies (node_modules) into a dedicated vendor bundle, we can minimize the primary application bundle size and optimize browser caching.
Problem
Currently, the project uses the default Vite build configuration, which frequently compiles application code and third-party dependencies into a single, large JavaScript bundle. Following the recent migration to Vite 6, leaving production assets unfragmented leads to larger initial page load sizes, slower time-to-interactive (TTI) performance, and prevents browsers from caching unchanged third-party libraries independently of rapidly changing source files.
Proposed solution
Modify the build configuration inside vite.config.js to utilize Rollup's manualChunks option. This will instruct the bundler to automatically identify imports originating from node_modules and split them off into an independent asset file.
The targeted configuration adjustment under the export statement will look similar to this:
JavaScript
build: {
rollupOptions: {
output: {
manualChunks(id) {
if (id.includes('node_modules')) {
return 'vendor';
}
}
}
}
}
Suggested scope
If you already know the likely implementation area, mention it here:
Suggested files or directories: vite.config.js located in the root directory of the repository.
Related route, page, component, API, or plugin: Build configuration and pipeline settings.
Acceptance criteria
List the minimum requirements for this feature to be considered done:
[ ] Production build configurations partition node_modules code into a unique chunk (e.g., vendor-[hash].js).
[ ] Running a production build compiles cleanly without warnings, syntax errors, or circular dependency breakage.
[ ] The localized dev server environment (npm run dev) remains unaffected and retains its rapid startup speed.
[ ] The bundled production application functions flawlessly in preview mode with zero runtime console regressions.
Test plan
Explain how a contributor or maintainer can verify the feature works.
Run a fresh production build locally using terminal command: npm run build.
Inspect the generated terminal output asset map under the dist/assets/ output.
Verify that a separate vendor asset chunk has been created alongside the standard index chunk.
Launch the local build preview via npm run preview and navigate the application dashboard to confirm that all assets load properly with zero runtime bundle errors.
Alternatives considered
Leaving configuration as default: Rejected because unoptimized chunks delay loading performance, particularly as the project adds more visualization or parsing modules.
Granular chunking per dependency: Rejected for now to prevent creating an excessive amount of small HTTP requests, sticking to a balanced single-vendor chunk approach instead.
Additional context
Optimizing the build architecture is highly beneficial as SecuScan scales up its dependencies under Vite 6. I'd love to implement this optimization—please assign this issue to me under GSSoC 2026!