Support .config/ dir

[pi0]

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-level vite.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 to DEFAULT_CONFIG_FILES array.

Alternatives

See relevant discussions.

Additional context

(sub-issue in vitest: vitest-dev/vitest#5204)

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that requests the same feature to avoid creating a duplicate.

[bluwy]

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:

1. It requires more fs checks for toolings to read the config.
2. The idea doesn't work for some tools, e.g. tsconfig.json, where the config applies to directory subtrees.
3. . directories may be hidden by some viewers.
4. While it's a chicken-and-egg problem, we can't know that every tooling will want to adopt this convention, and so there will likely be fragmentation to the ecosystem.
5. Using https://github.com/antfu/vscode-file-nesting-config feels like the best middleground if you care of the cleanliness of config files.

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 vite --config <path>.

With the above points, I'm closing this issue.

[pi0]

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:

It requires more fs checks for toolings to read the config.

The addition to support the alternative .config/ variant, does add no overhead to current projects because the check happens last. (it adds for when there is no config but I can argue vite already does 3 stat checks)

The idea doesn't work for some tools, e.g. tsconfig.json, where the config applies to directory subtrees.

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.

. Directories may be hidden by some viewers.

There is an open discussion. Also consider, that other tools such as .github and XDG config currently used with dot and common-editors (such as VSCode) do not hide dot dirs but rather sort it first.

While it's a chicken-and-egg problem, we can't know that every tooling will want to adopt this convention, and so there will likely be fragmentation of the ecosystem

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.

Using https://github.com/antfu/vscode-file-nesting-config feels like the best middle ground if you care about the cleanliness of config files.

No, it is not an alternative. We are fixing where the config is stored not how the config is accessible.

[patak-dev]

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. 🙏🏼

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.

It requires more fs checks for toolings to read the config.

The addition to support the alternative .config/ variant, does add no overhead to current projects because the check happens last. (it adds for when there is no config but I can argue vite already does 3 stat checks)

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.

Using https://github.com/antfu/vscode-file-nesting-config feels like the best middle ground if you care about the cleanliness of config files.

No, it is not an alternative. We are fixing where the config is stored not how the config is accessible.

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.

[pi0]

Converting to the discussion is a good idea 🙏🏼

If it goes last, it means that anyone adopting this will accept a slower startup due to the required previous 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.

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.

Will you explain why this distinction is important? I thought the important bit was about DX of having too many files in root.

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 EXPERIMENAL_CONF_DIR to enable supporting config dir? This allows progress across tools without putting support burden on vite.