refactor: common vitest configurations

[poltorak]

Centralize and Standardize Vitest Configurations

What Changed

• New centralized configuration system: Created testing/test-setup-config package with a factory-based approach for generating Vitest configurations
• Setup presets: Introduced modular setup file presets that can be composed for different test types (unit, integration, e2e)
• Simplified configuration files: Refactored 6 existing Vitest config files to use the new centralized system, reducing them from verbose configurations to simple function calls

Benefits

• Eliminates duplication: Removes repetitive boilerplate across multiple vitest config files
• Ensures consistency: Standardizes test configurations, coverage settings, and setup files across all packages
• Improves maintainability: Changes to test configuration defaults now only need to be made in one place
• Better developer experience: New configs are more readable and easier to customize with sensible defaults and preset combinations

The new system provides createUnitConfig, createIntConfig, and createE2eConfig factory functions that automatically handle common configuration patterns while still allowing customization through override parameters.

Relates to first part of #1065

[nx-cloud]

View your CI Pipeline Execution ↗ for commit 2772f2b

Command	Status	Duration	Result
nx code-pushup --nx-bail -- compare	✅ Succeeded	54s	View ↗
nx code-pushup --nx-bail --	✅ Succeeded	1m 3s	View ↗
nx code-pushup --nx-bail -- print-config --outp...	✅ Succeeded	3m 57s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-11-05 09:12:11 UTC

[pkg-pr-new]

Open in StackBlitz

@code-pushup/ci

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/ci@1107

@code-pushup/cli

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/cli@1107

@code-pushup/core

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/core@1107

@code-pushup/create-cli

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/create-cli@1107

@code-pushup/models

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/models@1107

@code-pushup/coverage-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/coverage-plugin@1107

@code-pushup/nx-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/nx-plugin@1107

@code-pushup/eslint-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/eslint-plugin@1107

@code-pushup/js-packages-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/js-packages-plugin@1107

@code-pushup/jsdocs-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/jsdocs-plugin@1107

@code-pushup/lighthouse-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/lighthouse-plugin@1107

@code-pushup/typescript-plugin

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/typescript-plugin@1107

@code-pushup/utils

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/utils@1107

@code-pushup/models-transformers

npm i https://pkg.pr.new/code-pushup/cli/@code-pushup/models-transformers@1107

commit: 2772f2b

[github-actions]

Code PushUp

🤨 Code PushUp report has both improvements and regressions – compared current commit a7b988f with previous commit c4b025c.

🕵️ See full comparison in Code PushUp portal 🔍

🏷️ Categories

🏷️ Category	⭐ Previous score	⭐ Current score	🔄 Score change
Performance	🔴 35	🔴 32
Code coverage	🟢 90	🟡 88
Security	🟡 56	🟡 56	–
Updates	🟡 73	🟡 73	–
Accessibility	🟢 92	🟢 92	–
Best Practices	🟢 100	🟢 100	–
SEO	🟡 61	🟡 61	–
Type Safety	🟢 100	🟢 100	–
Bug prevention	🟢 100	🟢 100	–
Miscellaneous	🟢 100	🟢 100	–
Code style	🟢 100	🟢 100	–
Documentation	🔴 36	🔴 36	–

👎 2 groups regressed, 👍 1 audit improved, 👎 7 audits regressed, 14 audits changed without impacting score

🗃️ Groups

🔌 Plugin	🗃️ Group	⭐ Previous score	⭐ Current score	🔄 Score change
Lighthouse	Performance	🔴 35	🔴 32
Code coverage	Code coverage metrics	🟢 90	🟡 88

19 other groups are unchanged.

🛡️ Audits

🔌 Plugin	🛡️ Audit	📏 Previous value	📏 Current value	🔄 Value change
Lighthouse	Initial server response time was short	🟩 Root document took 590 ms	🟥 Root document took 1,520 ms
Lighthouse	Speed Index	🟥 7.7 s	🟥 8.7 s
Lighthouse	Total Blocking Time	🟥 1,810 ms	🟥 2,510 ms
Lighthouse	First Contentful Paint	🟥 3.1 s	🟥 3.3 s
Code coverage	Function coverage	🟩 93.1 %	🟨 89.4 %
Code coverage	Line coverage	🟨 86.8 %	🟨 84.6 %
Lighthouse	Time to Interactive	🟥 13.4 s	🟥 14.1 s
Code coverage	Branch coverage	🟨 86 %	🟨 86.4 %
Lighthouse	Avoids enormous network payloads	🟩 Total size was 2,037 KiB	🟩 Total size was 2,099 KiB
Lighthouse	Minimizes main-thread work	🟥 13.0 s	🟥 14.5 s
Lighthouse	Largest Contentful Paint	🟥 11.8 s	🟥 12.6 s
Lighthouse	Metrics	🟩 100%	🟩 100%
Lighthouse	Uses efficient cache policy on static assets	🟨 30 resources found	🟨 30 resources found
Lighthouse	Remove duplicate modules in JavaScript bundles	🟥 Potential savings of 103 KiB	🟥 Potential savings of 86 KiB
Lighthouse	Reduce unused JavaScript	🟥 Potential savings of 181 KiB	🟥 Potential savings of 180 KiB
Lighthouse	Server Backend Latencies	🟩 1,480 ms	🟩 1,600 ms
Lighthouse	Avoids an excessive DOM size	🟥 2,255 elements	🟥 2,371 elements
Lighthouse	JavaScript execution time	🟥 5.4 s	🟥 5.3 s
Lighthouse	Network Round Trip Times	🟩 30 ms	🟩 60 ms
Lighthouse	Max Potential First Input Delay	🟥 1,430 ms	🟥 1,450 ms
Lighthouse	Reduce unused CSS	🟥 Potential savings of 103 KiB	🟥 Potential savings of 62 KiB
JS Packages	Outdated NPM prod dependencies.	🟨 17 outdated package versions (6 major, 7 minor, 4 patch)	🟨 18 outdated package versions (6 major, 7 minor, 5 patch)

588 other audits are unchanged.

[BioPhoton]

Thanks for cleaning up our test config mess :)

I left some comments.

• please add a proper PR description that contains the scope and planned changes
• move the config code under a Nx project in testing/vitest-setup. I updated the issue accordingly.

[BioPhoton]

Thanks for the changes! Nice testing tool! There is Readme, and tests, lovely.
I left some first comments and will wait for one feedback on the override logic for further comments.

[matejchalk]

Hi, thanks for your contribution 🙂 I think it looks promising, but ...

I don't think this PR goes far enough towards unification. Ideally, only 2 parameters¹ would determine the entire Vitest config:

• Nx project name (e.g., cli, plugin-eslint, ci-e2e) ²
• test kind ('unit' | 'int' | 'e2e')

My main criticism of this PR is that it doesn't commit to unification over flexibility. I believe we need less flexibility than it may appear, so I would go all in on unification. If we find some exception, we should question whether that exception is justified and get rid of it if possible.

In the current implementation, some things are automatically inferred, but there are many (IMHO unnecessary) optional arguments, and anything can be overridden by providing a Vitest config object. To me, this is a leaky abstraction.

I've suggested specifics on what can be unified in my comments. Let me know if I can clarify anything 🙂 I realize you couldn't reasonably have known many of these things, so no worries.

Footnotes

1. By "parameter", I don't strictly mean a function parameter. Your approach of exporting different factory functions for each test kind also works, for example. ↩

2. It may turn out we also need something like projectRoot (e.g., 'packages/core'). In that case, we could either derive it via @nx/devkit's createProjectGraphAsync, provide the project folder instead and derive its name using path.basename, or add another parameter. ↩

[matejchalk]

I think this is headed in the right direction. I also reviewed the internal implementation this time, where I have some minor suggestions.

However, I think the pattern is now fairly clear, so please go ahead and apply it to other Vitest configs. 🙏

[matejchalk]

Almost there 🤞

[matejchalk]

All good, thanks for your persistence 👏