Change env var prefix

[benmccann]

Describe the problem

Vite will now let you change VITE env var prefix to be something else like PUBLIC or CLIENT

Describe the proposed solution

vitejs/vite#4676

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[JeanJPNM]

Do we have to do something? I mean, if it is on the vite config we just need to bump the version of vite right?

[benmccann]

yeah. and I think we should change our default and document it

[dreitzner]

Maybe KIT? Would it make sense to expose it in the config, because it would be a breaking change?

[benmccann]

I sent a PR to accept both VITE_ and PUBLIC_ so that it won't break existing applications

[Rich-Harris]

Isn't this just an extra thing people have to learn? If someone knows Vite (and to become expert in SvelteKit, they will eventually need to know their way around Vite, at least a bit) then they will know about VITE_, and if they see it without context then they'll likely understand that it's a Vite feature (and therefore that they can learn about it on https://vitejs.dev/).

By contrast I don't think I would immediately know what PUBLIC_ was unless I happened to have read the relevant part of the docs (or rather the FAQs, per #2355). It feels like this could be left to user config, rather than increasing the surface area of SvelteKit-specific idioms that people need to learn.

[benmccann]

It is an extra thing to learn to some extent, but if you don't know about PUBLIC_ I don't think there's much harm that would come from it. You'd simply create all your environment variables with a VITE_ prefix instead and you could carry on your marry way in bliss. Or if you read code in a project you weren't familiar with and you saw PUBLIC_ you might not know that was needed to access it on the client, but by the same respect you also wouldn't know that VITE_ was needed either unless you read the docs or had some prior Vite familiarity. The worst thing that would happen in that case is you might create one with a VITE_ prefix when the project was using a PUBLIC_ prefix and it'd be an extra comment in code review

[Karlinator]

Is there a specific reason why you suggest PUBLIC_? It's a pretty well-established pattern generally to use the framework name as a prefix is it not?. VITE_, REACT_APP_, etc. My first thought would probably be to use KIT_, though I don't have any strong opinions on that.

I agree that, though the reasons make sense, it has always been a little weird to put VITE_ everywhere when the immediate framework is SvelteKit.

[benmccann]

I didn't know that was becoming a pattern. I hadn't seen REACT_APP_ before. It looks like there's also SNOWPACK_PUBLIC_. I'm not sure it's a pattern I particularly like, but I guess it is what it is. In my mind it seems odd to name your variables after the framework you're using. PUBLIC_ is more informative and denotes what it does. But it is harder to discover if you need to search for it since it's less unique

[benmccann]

I'm going to go ahead and close this. Everyone's got a bit different opinion about it and it would make the behavior diverge from VITE which might add as much confusion as it would solve. If you'd like to configure this, you can do so in your svelte.config.js

[arxpoetica]

This may have already shipped (?), but I'd opine that something like GLOBAL_ or KIT_ is easier to make sense of than PUBLIC_ from a first comers perspective. public...what? Public has very different connotations in different scenarios.

[benmccann]

this was left as VITE_. you can configure it on a per-project basis using the Vite configuration options