refactor: always use a cache directory

[ArnaudBarre]

Description

I'm currently working #4120 and I found that it adds some complexity to handle a nullable cacheDir. The only case it can happened is when there is no package.json detected, which seems a niche case. I suggest to use .vite as a cache directory in that case. We could also keep the default of node_modules/.vite but it makes less sense in that case.

Additional context

While looking for usage of cacheDir, I found that the caching of the certificate was dropped in #5514. I adding it back except if there was a reason to remove it (cc @patak-dev)

Note: This could technically be a breaking change for people using a global installation of Vite in projects that don't use a package manager.

[patak-dev]

This looks good to me, and good catch about the certificate

see comment

[patak-dev]

@ArnaudBarre after a discussion with @dominikg, looks like global usage of vite may also be affected by this change.

Would you split this PR in two so we can merge the cache dir fix before releasing 2.8? Thanks!

[ArnaudBarre]

Let me know about the decision for this change.

Another option as suggested by @gluck is to allow to disable caching. This would be easy (adding | false) to the cacheDir option and updating some messages. But it would start to conflict with server.force (and would keep adding a bit of complexity each time a new feature need to handle file system caching)

[Shinigami92]

Code LGTM

[patak-dev]

I'm leaning towards allowing to disable caching. We're only going to be able to discuss this in the next team meeting (next Friday), I'll bring the topic there.

[patak-dev]

@ArnaudBarre @dominikg we talked about this PR in the last team meeting, and we concluded that it is a good idea to always have a cache. The DX in Vite is heavily damaged without it, and we don't have a real use case at hand for justifying the complexity of allowing Vite to run without write access during dev. Vite can also be safely run globally if the cache is held at the root of the Vite project. @ArnaudBarre would you resolve the conflicts and confirm that this looks good to you?

[Shinigami92]

Just to be clear, this should land in a minor release due to this potential breaking change:
https://github.com/vitejs/vite/pull/6415/files#diff-db0f5f8dbaa7b2beda67cfc9f12bc0d22dedbbc7ed3d1935b3fdd5a3a7991350R125
Potentially this could be access from outside

[patak-dev]

What do you mean by "potentially this could be access from outside"?

The idea is to merge it now that we are in the 2.8 beta period, so it will be included as part of a minor 👍🏼

[Shinigami92]

I just mean it is now a required parameter and typescript would report an error, nothing more
But as you say it is already planned to 2.8, everything is fine 🙂

[patak-dev]

But resolveHttpsConfig is an internal function, no?

[Shinigami92]

export async function resolveHttpsConfig
^^^^^^

[patak-dev]

That function is only imported as an internal utility by other files, or maybe I'm not seeing where it is exported to the user

[Shinigami92]

@patak-dev https://www.typescriptlang.org/tsconfig#stripInternal 👀