Rename `$app/env` to `$app/something`

[Rich-Harris]

Describe the problem

#5663 adds a new set of modules — $env/static/private, $env/static/public, $env/dynamic/private and $env/dynamic/public. These explicitly relate to environment variables aka 'env vars', and as such it's mildly confusing that env is also used in $app/env to mean something completely different.

The values exported from $app/env are browser, dev and prerendering.

Describe the proposed solution

I like $app/mode, since browser, dev and prerendering are all modes the app is running in. The one downside to that — it uses a word that Vite means something else by — seems very inconsequential (software using words in different ways is far from a new phenomenon).

Alternatives considered

$app/type and $app/static have been suggested. I don't personally love these — type suggests a fixed characteristic of the app, and static merely describes a quality that browser/dev/prerendering have while the app is running, without saying anything about what they are.

My first thought was $app/context, since everyone loves a bit of context. But we've been here before.

Importance

nice to have

Additional Information

No response

[Mlocik97]

$app/mode is fine for me.... hope you will not name it literally $app/something that would be worse than stuff.

[elliott-with-the-longest-name-on-github]

I'm fine with $app/mode.

[kelvindecosta]

How about $app/phase or $app/stage?

[f-llewellyn]

Could $app/target be used, as browser, dev and prerendering are all "targets" per say that SvelteKit builds to? Could be short for "target mode" or "target environment"?

I'm unsure if this is used for anything else as I'm a bit of a n00b, but my thoughts were that this could avoid potential head scratching/dev time, otherwise caused by the Vite naming conflict.

[f-llewellyn]

Just done some quick research and it appears that the idea of "targets" is used quite heavily in adaptors for different hosting platforms (Vercel, Netlify etc.), so maybe not a great idea to just move the lack of clarity in existing terminology from one place to another. 🙂

[rmunn]

While I'm fine with $app/mode, this seems like the right time for bikeshedding, so I want to suggest $app/runtime for consideration. Or $app/runtimeEnv or some such thing, but we don't want it to be too long so I don't think runtimeEnvironment would be a good idea.

So basically, $app/runtime.

[novotionyx]

While I'm fine with $app/mode, this seems like the right time for bikeshedding, so I want to suggest $app/runtime for consideration. Or $app/runtimeEnv or some such thing, but we don't want it to be too long so I don't think runtimeEnvironment would be a good idea.

So basically, $app/runtime.

Sounds good, but prerendering doesn't really seem to fit in with the idea of runtime.

[ZetiMente]

I would like to vote against "mode" for the reason you said. Vite uses it: mode: process.env.MODE || 'development'

[elliott-with-the-longest-name-on-github]

If we wanted to be a bit cheeky, $app/where or $app/whereami (I like the last one 😉) could actually work pretty well. "I'm in development", "I'm prerendering", and "I'm in the browser" are all valid answers to the question, and it's a fun and memorable name.

[antony]

Absolutely vote against mode for obvious reasons. It feels a bit like $app/flags or $app/attributes though that strikes me as a little generic (a bit like util), I'd prefer $app/modes instead of $app/mode since in reality, both dev and browser could be true. but still a little overloaded because of MODE.

[rmunn]

Sounds good, but prerendering doesn't really seem to fit in with the idea of runtime.

Agreed, but it's the best I've found so far. Unless $app/runmode would be better, but I don't like that as much as runtime.

Also, $app/runtime feels like a place where other things might usefully be put in the future, not just the browser / dev / prerendering flags. Whether that's a positive or a negative, I don't have a feel for yet.