You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to a lack of standards for where tools store their configuration, the number of top-level configuration files in projects is increasing day by day. See .config dir proposal for more context.
Suggested solution
I propose supporting .config/vitest.js and .config/vitest.config.js as alternative places to check and load vite configuration if top-level vitest.config.ts does not exist to unblock adopting this new convention across the ecosystem.
Is it too early? While it can take a while to onboard more tools with this new convention, it will be an egg-and-chicken problem to adopt a new convention like this unless more mainstream tools onboard to support it.
Clear and concise description of the problem
Due to a lack of standards for where tools store their configuration, the number of top-level configuration files in projects is increasing day by day. See
.config
dir proposal for more context.Suggested solution
I propose supporting
.config/vitest.js
and.config/vitest.config.js
as alternative places to check and load vite configuration if top-levelvitest.config.ts
does not exist to unblock adopting this new convention across the ecosystem.Is it too early? While it can take a while to onboard more tools with this new convention, it will be an egg-and-chicken problem to adopt a new convention like this unless more mainstream tools onboard to support it.
Implementation
It seems we can easily append
.config/
variants toCONFIG_NAMES
andWORKSPACE_NAMES
arrays.Alternative
See relevant discussions.
Additional context
(parent issue in vite: vitejs/vite#15911)
Validations
The text was updated successfully, but these errors were encountered: