-
-
Notifications
You must be signed in to change notification settings - Fork 6.1k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support .config/
dir
#15911
Comments
Thanks for bringing up this proposal. I've brought this up to the team to discuss, and we have agreed that this isn't something we want to support. To summarize the points:
If I may add my personal opinion, I don't think moving config files into a new directory solves problems. It merely shifts the problem somewhere else. If there's many config files to grasp, perhaps the user should reduce their tooling used instead. Otherwise if it's for organisational purpose, tooling often expose a flag to explicitly set the config path too, like With the above points, I'm closing this issue. |
Thanks for the feedback dear @bluwy but maybe it is something we can have a more thorough discussion that where I/others can be involved too? It seems a quick decision had been made without the chance of any further discussion. In the meantime, I suggest to keep this issue open to collect more feedback and give more chances for discussion, it is an ecosystem-wide change. 🙏🏼 Quickly answering some of your points:
The addition to support the alternative
Although this is perhaps a separate scope for how tsconfig can opt-in, we can simply assume the parent as the root when the file is in dir. It is not an impossible situation, it is another open issue.
There is an open discussion. Also consider, that other tools such as
The current fragmentation (and honestly blocker) is tool support rather than usage fragmentation. I expect users to stick with the top level until the majority of the tools they use allow opting into the new standard place. But it won't happen before.
No, it is not an alternative. We are fixing where the config is stored not how the config is accessible. |
The issue wasn't quickly closed, the points raised by Bjorn were discussed between several Vite team members. I think closing the issue is ok to send a signal and avoid making people do extra work, like the PR to implement this feature if we don't think at this point this will be adopted. It doesn't prevent further discussion, and we can re-open it later. All good with that. If you are ok with it, we could convert it to a discussion so there is no concept of open or closed and we can also have proper threads.
If it goes last, it means that anyone adopting this will accept a slower startup due to the required prev checks. We could use our dir-based fs cache scheme to reduce these checks though, so the stat checks may not be a blocker here.
Will you explain why this distinction is important? I thought the important bit was about DX of having too many files in root. vscode-file-nesting-config does look like a good solution for that, but maybe we are missing something here. |
Converting to the discussion is a good idea 🙏🏼
Yes, indeed it would be a compromise. This is an attempt to unblock new convention rather than something we push to adopt today + indeed an fs-cache boost can be useful as more users/tools want to allow opting-in we probably need to think about perf improvements and shared cache.
This attempt is to push for a standard place to store, read, and document config files (when the majority of tools allow opt-in). When browsing a GitHub repository, the config files make repo onboarding harder it is also one of the main goals to make top-level universally better, cleaner, and more maintainable. If I may propose something in the meantime, would Vite be open to considering respecting an agnostic experimental env variable such as |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Description
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/vite.js
and.config/vite.config.js
as alternative places to check and load vite configuration if top-levelvite.config.ts
does not exist to unblock adopting this new convention across the ecosystem.Is it too early for Vite? 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 toDEFAULT_CONFIG_FILES
array.Alternatives
See relevant discussions.
Additional context
(sub-issue in vitest: vitest-dev/vitest#5204)
Validations
The text was updated successfully, but these errors were encountered: