Closed blittle closed 1 year ago
import.meta.env
wouldn't work in non-ESM environments, like CJS.
What are the reasons process.env
isn't ideal?
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?
@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.
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.
@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.
@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?
@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:
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 :)
@maxshirshin I agree with that, and that's kinda the point of the import.meta
object. But that is restricted to ESM environments.
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.
Should this be closed in favor of https://github.com/wintercg/environment-metadata/issues/1 as the workstream has been established?
Should there be a standard global location to access runtime variables?
Options:
process.env
import.meta.env