Support import.meta.env

[JounQin]

Feature request

What is the expected behavior?

import.meta.env.NODE_ENV

What is motivation or use case for adding/changing the behavior?

migrate process.env.NODE_ENV

How should this be implemented in your opinion?

No idea

Are you willing to work on this yourself?

No idea

[vankop]

which tools support it? only Vite.js?

[philippevezina]

which tools support it? only Vite.js?

To my knowledge yes.

Webpack 5 has taken a big step by stepping away from Node in bundled code by removing NodeJS library polyfills from being included in bundles. Removing process seems like the next big step in the same direction.

ViteJS also provides a powerful tool to replace CommonJS require statements: import.meta.glob and import.meta.globEager.

[vankop]

yeah, webpack supports import.meta.webpackContext #15446

[alexander-akait]

To be honestly I am always thinking what we should use globalThis to check env, i.e. globalThis.ENV /globalThis.NODE_ENV/etc , import.meta only for import meta and functions related to import (hot replacement/resolving/etc), not sure why we should store env in import.meta.env, also using globalThis is solution for any platform - browser/node/deno, import.meta.env only for bundlers, and you need again using bundler to change it, just my option

[alexander-akait]

For example we can found many issues like immerjs/immer#557 (and workaround immerjs/immer#557 (comment)) for these packages, import.meta.env is an unofficial solution for any platform.

[alexander-akait]

Anyway we can merge #15841 to solve problems with packages which already migrate on import.meta.url, but the question is more bigger, will be great if developers from Node.js, Deno, Rollup, Parcel, Esbuild and other had an discussion here. It is not good that vite just decide to use import.meta.env for env and start to recommend it, it can be destructive for ecosystem.

[binyamin]

@alexander-akait Just FYI, I looked at the tc39 proposal for import.meta. It seems the ECMAScript committee decided it should be extensible.¹ Particular hosts, such as Node.js and Deno, may lock down the API if they choose. I wouldn't extend it for a Node.js script. But in the browser, it's fair game.

Footnotes

1. https://github.com/tc39/proposal-import-meta#will-this-object-be-locked-down-in-any-way ↩

[webpack-bot]

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

[alexander-akait]

bump, still need a dicussion (anyway it can be done using a plugin)

[XiaoLin1995]

You can try to use import-meta-loader.
It will support you to use vite's import.meta in webpack. Because it can convert vite's import.meta syntax to webpack's syntax.

example:

// vite => webpack
import.meta.env //=> process.env
import.meta.env.MODE //=> process.env.NODE_ENV
import.meta.env.BASE_URL //=> process.env.BASE_URL
import.meta.env.PROD //=> process.env.NODE_ENV === 'production'
import.meta.env.DEV //=> process.env.NODE_ENV !== 'production'

new URL('filePath', import.meta.url).href //=> require('filePath')

import.meta.glob('filePath') //=> ... require.context('dirPath', useSubdirectories: boolean, RegExp, 'lazy') ...
import.meta.glob('filePath', { eager: true }) //=> vite3 ... require.context('dirPath', useSubdirectories: boolean, RegExp, 'sync') ...
import.meta.globEager('filePath') //=> vite2 ... require.context('dirPath', useSubdirectories: boolean, RegExp, 'sync') ...

[JounQin]

I'm like to have a more standard way because process is not standard global variable.

[webpack-bot]

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

[silverwind]

The modern way of doing it in node is an explicit import:

import {env} from 'node:process';
console.info(env.NODE_ENV);

Maybe the runtime code of webpack could export it? Using special webpack: protocol which ensures the module is not a valid npm name:

import {env} from 'webpack:runtime';
console.info(env.NODE_ENV);

Could be used for other stuff as well:

import {setPublicPath} from 'webpack:runtime';
setPublicPath('/');

The only downside is that import protocols are to my knowledge not standardizes by ECMA, so it's pretty much a node-only convention at this point.

[saolof]

I'd rather encourage the explicit import as mentioned above than rely on the bundler monkey patching attributes global variables that are then used in the code, after just having been bit by the problem.

The dependency on the .env attributes leads to code that fails at runtime if you build it with the wrong bundler. This is just technical debt imposed on anyone that uses a bundler with this kind of API in their projects, and that future linter authors will have to add a rule for.