Document existing use of env property #7
Conversation
|
I wonder if we need a "status" column in this table where we distinguish between "known convention" and "experimental" and "recommended standard"? This seems like a place where explicitly documenting this as a convention rather than a recommended standard could be useful. |
jkrems
force-pushed
the
jk-import-meta-env
branch
from
08221b6
to
8f50315
Compare
|
I added a proposed "status" column that expresses two dimensions:
|
README.md
Outdated
| * 🛑 **Discouraged:** There's a better, more interoperable alternative to using this field that should be used instead. | ||
|
|
||
| Stability level: | ||
| * 🪨 **Stable:** Field has a clear specification and tests to ensure interoperable behavior. Deviation from the specified behavior is likely a bug in a runtime. |
There was a problem hiding this comment.
On Windows this emoji is coming up as unknown for me currently.
README.md
Outdated
| * ✅ **Baseline:** Code can generally expect this field to be present and runtimes should generally implement it. | ||
| * ☑️ **Optional:** The field may be unavailable in certain environments. Code should handle the field's absence to be fully portable. |
There was a problem hiding this comment.
Maybe these can be Baseline standard and Optional standard?
jkrems
force-pushed
the
jk-import-meta-env
branch
from
8f50315
to
bd05de5
Compare
|
@ljharb Any thoughts on this one? It has no objections yet but the bit missing is an approval from a wintercg member. |
|
I wonder if it would be worth adding this to the meeting agenda? |
|
I'm also starting to suspect that I may be misunderstanding the goals of the registry. I was looking for a place that documents meta properties that are in active use to identify potential interop risks etc.. But from the PR comments, it doesn't sound like that's what this registry is..? If the registry is just for "recommended & interoperable standard properties across WinterCG-aligned runtimes", then this PR might just be sent to the wrong repo. :) |
Alternative to #5 that focusses on documenting the status quo instead of suggesting a specific spec for the
envfield.I'm explicitly not using "environment variables" in the description because in Vite it contains things like
.DEV/.PRODwhich are booleans and very much not environment variables. See also: semantics are currently inconsistent and not fully interoperable.Happy to add a "please don't add unflagged in more places until semantics are specified", to me the "Warning" already implies that.