Standard access to runtime variables

[blittle]

Should there be a standard global location to access runtime variables?

Options:

1. process.env
2. Dump runtime variables directly on the global
3. Utilize import.meta.env

[ljharb]

import.meta.env wouldn't work in non-ESM environments, like CJS.

What are the reasons process.env isn't ideal?

[blittle]

Great question @ljharb. Maybe this comes back to something @jasnell mentioned in a recent meeting, "what are the guiding principles" for standard APIs? Is CommonJS compatibility apart of those principles?

[ljharb]

@blittle CJS and ESM are both first-class module systems in node for the foreseeable future, and most of npm (and thus most of the world's public package code) is CJS by a very very large margin, so I'd argue that anything that doesn't maintain CJS compatibility is making a pretty large misstep.

[jasnell]

Misstep or not, the idea with the common minimum spec is to document the common already standardized api surface area for the runtimes. This is something we likely should discuss in its own workstream.

@ljharb

What are the reasons process.env isn't ideal?

process is a Node.js specific API that is not standardized. It is not even a CommonJS thing. Deno has its own API for environment, Workers has its own mechanism for accessing the environment, and it's just not yet clear what a standardized overlapping surface area should be.

Also consider that a goal here is to focus on alignment with the Web ecosystem ... specifically, what approach could work for browsers also. For that, a proposal for something like a navigator.env could make sense, where env exposes a map-like API might be interesting. Why navigator.env? Well, specifically because it is not the platform specific options that the runtimes already implement today (Node.js is on the Node.js specific process object, Deno's is on the Deno-specific Deno object, Cloudflare's is currently injected differently depending on which worker syntax you're using). navigator.env would be available to both CommonJS and ESM and wouldn't clash with anything else that exists.

[ljharb]

@jasnell "env vars" as a concept simply don't make any sense in a web browser, so i'm not sure what approach would work for browsers. "env" is "environment", and in the web there's only one environment, and no consistent way for users to invoke it with different "environmental input".

This seems like a new API, that should first be proposed to WHATWG.

[XadillaX]

@jasnell "env vars" as a concept simply don't make any sense in a web browser, so i'm not sure what approach would work for browsers. "env" is "environment", and in the web there's only one environment, and no consistent way for users to invoke it with different "environmental input".

This seems like a new API, that should first be proposed to WHATWG.

So we should now working on a new whatwg api first?

[maxshirshin]

@blittle I think the ability to read some external meta data is very important, but a "runtime variable" is an ambiguous concept in a JS runtime context. Normally, runtime vars and their properties are OS-specific, while JS runtimes (in general) don't have the concept of a "host operating system". If we think more about env vars, multiple issues pop up, like:

• Are var names case-sensitive?
• What if a user redefines them? sets a new one?
• How does a runtime know if it's authorized to access a variable?

Could we, instead of "runtime vars", use a more generic term like "external metadata" and think if we can have a standardised API for it? It should of course be able to cover the runtime vars use case :)

[blittle]

@maxshirshin I agree with that, and that's kinda the point of the import.meta object. But that is restricted to ESM environments.

[jasnell]

It makes a ton of sense to devise some common API around this for both ESM and non-ESM environments. This should be its own workstream, however.

[legendecas]

Should this be closed in favor of wintercg/environment-metadata#1 as the workstream has been established?