vitejs / vite

Next generation frontend tooling. It's fast!
http://vite.dev
MIT License
68.4k stars 6.17k forks source link

Use standard path for cache directory #17444

Closed rtritto closed 4 months ago

rtritto commented 4 months ago

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:

Related #17429

Reproduction

No response

Steps to reproduce

No response

System Info

No response

Used Package Manager

npm / yarn / pnpm

Logs

No response

Validations

bluwy commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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

patak-dev commented 4 months ago

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 commented 4 months ago

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