I just noticed that Snowpack recently merged in support for
import.meta.env being a replacement for the
process.env global variable that is typically used in Node.js application workflows (and browser workflows through bundlers) to set environment state information.
I thought it would be interesting to discuss if the browser might consider something similar.
The most typical use case for this is the
process.env.NODE_ENV === 'production' check which has become a JS idiom and not just a Node.js one. See for example React for the browser shipping this here - https://firstname.lastname@example.org/index.js.
In the transition to ES modules, it would be nice for users not to try to maintain the same
process global being “shimmed” for the browser, but instead to have an idiomatic way of doing this for ES modules.
The alternatives seem to be globals, an
import env from 'env' module or always requiring a precompilation step like Snowpack has shipped which adds a line to the top of every module containing
import.meta.env = env.
The alternatives do have the problem of not providing a pattern that can be used in portable code such that fragmentation or convergence on a pattern that won’t be supported in browsers seems to be a risk otherwise.
Perhaps giving the browser control over such a variable would provide a useful alignment for tools while continuing to allow idiomatic modular code to run in browsers without a build step being a mandatory prerequisite?
It would be great to hear thoughts further on this topic.