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.

[coryvirok]

$app/mode seems fine. Although this is a category of naming issue that might crop up again. E.g. if you add something else like mode.

Alternatively, you could create $env/static/sveltekit/XXX as a namespace to store stuff like this and future proof the category of naming issue.

[ammarriq]

Maybe something like $app/state

[schelv]

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.

I think runmode is a good one. runtime could be ambiguous. runmode has information about the mode the application is running in.

[thisispete]

forgive my lack of context, would it make sense at all to move it under $env/ ?

$env/runtime/mode

some other synonym words that come to mind: /basis /detail /use

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

forgive my lack of context, would it make sense at all to move it under $env/ ?

$env/runtime/mode

some other synonym words that come to mind: /basis /detail /use

We talked about this internally IIRC. I think the conclusion was that we'd prefer to keep $env as a namespace for user-provided stuff.

[madeleineostoja]

I feel like the $app/runtime proposal is a little more future proof / broad than $app/mode because it describes any kind of environmental state about your current app (ie: runtime), whereas I feel like the "mode" you're in is a subset of that. Both are good suggestions though, as long as we don't end up with another stuff

[Rich-Harris]

$app/runtime is definitely a viable option, though it does feel a bit like it refers to 'the SvelteKit runtime' and should therefore expose various functions.

Personally I like @antony's suggestion of $app/flags the best out of all the suggestions so far — it feels env-y, and is clear that it exports boolean values (but could stretch to accommodate a string or two in future if it absolutely had to). Does anyone have strong feelings about that?

[benmccann]

I don't like $app/runtime because those values will take effect at build time and not runtime

I don't particularly like $app/flags because it will restrict us to boolean values

Honestly, at this point it's been $app/env long enough since the new environment variable stuff was introduced that I'd be perfectly happy leaving it as is since I haven't seen people confused by it.

Other options could be $app/config or $app/settings

[madeleineostoja]

I don’t like config or settings because both of those imply that it’s stuff that was (or could be) configured by the user, which isn’t the case.

I like flags better than mode as again I see mode as a subset of flags. I don’t have any insight to the sveltekit roadmap but if restricting this “thing” to boolean or enums (I think enums are a flag, but arbitrary string value aren’t?) is limiting then that’s a valid concern.

I think “runtime while building” isn’t too much of a stretch, but I agree with Rich’s concern that the user might expect or more robust module than just a few values from a runtime export.

I agree that app/env isn’t a HUGE problem, but while we’re breaking and remoulding stuff it’s low hanging fruit to clean up because it’s also not ideal.

Idk naming stuff is hard

[Rich-Harris]

I don't particularly like $app/flags because it will restrict us to boolean values

My take on this is 'if we add a new thing that isn't a boolean it probably doesn't belong in this module'. Do you have an example of the sort of thing we might add that a) would be grouped with browser, dev and prerendering but b) isn't a boolean (or perhaps a string)?

[Rich-Harris]

those values will take effect at build time and not runtime

minor point of fact 😀 prerendering is set at runtime, via the not-so-secret override function. but it's the only one of the three

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

My take on this is 'if we add a new thing that isn't a boolean it probably doesn't belong in this module'.

My feeling on flags has always been "boolean, enum, or string literal union", which is pretty flexible here and definitely encompasses everything currently in the module.

[benmccann]

$app/state and $app/status are two more options

I agree config and settings are probably no good as they do sound like they'd be set by the user. Though I have the same reaction to flags, which is my biggest reason for not liking it. It makes me think of CLI flags

Do you have an example

The build time could be exposed as a Date or number. Depending on whether or not strings are viewed as problematic, there are enums. E.g. build: 'client' | 'server' | 'service-worker'. Another thing might be the app version, which I also believe is a string.

[ajayhada]

What about

1. $app/runin(run in) since browser, dev and prerendering are all modes the app is running in

2. $app/runtime/mode also a good option.

$app/flag, $app/runtime and $app/mode are good option but too generic

[Rich-Harris]

Ok, last try: $app/environment. Here me out: all the other ideas we've had are either nonsense made up words (sorry, runmode and runin won't fly), or have bad connotations (e.g. @benmccann pointed out that flags are also things that the user sets, like config and settings). The most upvoted idea, runtime, doesn't really make sense — of the three values, two are set at build time, none of them change during the life of the app, and none of them refer to either the browser runtime or the SvelteKit runtime.

'environment' truly is the best option. I see our best options as being:

1. Keep $app/env and accept the ambiguity with $env
2. Change to $app/environment so that it's a full word (like its siblings — paths, stores, navigation) and is neatly disambiguated from the the kind of env people associate with process.env

I prefer option 2, even though people will likely view it as a needless breaking change and complain that they have to write extra characters (which isn't really true — I can't remember the last time I typed it out while coding because VSCode always does it for me, and would certainly autocomplete if I typed $app/e).

[Mlocik97]

option 2 sounds really good. $app/environment :+1:

[LukasParke]

I really like $app/flags just my two cents

[madeleineostoja]

I think that’s a good compromise, environment is better than env, and it’s not another context or stuff so it’s at least not a step backwards

[GauBen]

I'm a bit late to the party, but I like $env/app. What it exports make more sense to be in $env than in $app.