kit
kit copied to clipboard
Rename `$app/env` to `$app/something`
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
$app/mode
is fine for me.... hope you will not name it literally $app/something
that would be worse than stuff
.
I'm fine with $app/mode
.
How about $app/phase
or $app/stage
?
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.
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. 🙂
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
.
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
.
I would like to vote against "mode" for the reason you said. Vite uses it: mode: process.env.MODE || 'development'
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.
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.
Sounds good, but
prerendering
doesn't really seem to fit in with the idea ofruntime
.
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.
$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.
Maybe something like $app/state
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 asruntime
.
I think runmode
is a good one.
runtime
could be ambiguous.
runmode
has information about the mode the application is running in.
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
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.
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
$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?
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
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
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)?
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
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.
$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.
What about
-
$app/runin
(run in) sincebrowser
,dev
andprerendering
are all modes the app is running in -
$app/runtime/mode
also a good option.
$app/flag
, $app/runtime
and $app/mode
are good option but too generic
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:
- Keep
$app/env
and accept the ambiguity with$env
- 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 ofenv
people associate withprocess.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
).
option 2 sounds really good. $app/environment
:+1:
I really like $app/flags
just my two cents
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
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
.