Use standard path for cache directory

[rtritto]

Describe the bug

The default path of cacheDir option should be .vite and not node_modules/.vite.

node_modules is used for dependency and not for cache files.

Cache directories should be at root of project.

Some points:

• Next.js creates a .next directory with all temporary files inside
• Plug'n'Play (PnP) does not use the node_modules directory for dependencies

Related #17429

Reproduction

No response

Steps to reproduce

No response

System Info

No response

Used Package Manager

npm / yarn / pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[bluwy]

Vite has defaulted to node_modules/.vite for a long time and I don't think there's any benefit to changing that now. We would have to force every metaframeworks to configure gitignore or change the cacheDir somewhere else.

[rtritto]

@bluwy
This change can be added in a major release as a breaking change (it's not so breaking and complicated at all).
Cache directory is hidden under node_modules directory and it's not a best practice. An user must open node_modules directory to check if the cache was generated, it isn't directly visible.
Vite, as defaults and behaviors, should be usable, clean and preserve standards (best practices).
If needed and can help, I can create a PR to support this change.

[bluwy]

I don't think there's any reference that said using node_modules is not best practice? Many tools also cache within node_modules. You also don't need to open the cache directory yourself unless you want to debug things, so being tucked inside node_modules make sense. If there isn't a significant benefit other than best practice, then I don't see why we should create churn for everyone that uses Vite.

[rtritto]

@bluwy

I don't think there's any reference that said using node_modules is not best practice?

node_modules directory has been choosen because the first and only node linker was node modules.
Isn't a best best practice because the Vite's defaults should not be preferred for a specific node linker and an user should be free to change the cache directory only if needed and not because standard isn't generic.
All new and modern projects use a single and visible directory to group temporary files because is free to scan and watch (i.g. .gitignore, scripts etc).

You also don't need to open the cache directory yourself unless you want to debug things, so being tucked inside node_modules make sense. If there isn't a significant benefit other than best practice, then I don't see why we should create churn for everyone that uses Vite.

node_modules should contains only dependency and not cache. I don't know why mix a think that isn't directly related.
If you want to remove (prune) only dependencies in node_modules and not the Vite's cache, you must do a trick (exception) to ignore the .vite directory.
It's an unexpected use of node_modules directory...
The change is a simple improvement (basic migration) and users can choose if upgrade or not to a major version. For new users, it's also easier to understand and use if the Vite's cache directory is explicit.

[patak-dev]

Frameworks can choose a different cacheDir if they would like for their users. This is the first time that the cache under node_modules has been raised as an issue. I haven't seen any of them change it before. The cache was originally under node_modules because it was caching pre-bundled dependencies. If you nuke your node_modules, is a good idea for the cache to be deleted too.
While I think that a /.vite cache has some potential benefits too (cleaner paths, better Plug'n'Play story), I agree with @bluwy that this will cause too much churn in the ecosystem and it is not worth doing at this point.

[rtritto]

@bluwy @patak-dev
Can this issue be added as future improvement/change (TBD)?

[patak-dev]

I don't think we'll be doing this in the next few majors, and to be honest, the ecosystem will only get larger so it will be harder and harder to justify this change. I think it is better to keep this closed.

[rtritto]

@bluwy @patak-dev
If the ecosystem will be larger, this should be done before it.