The webpack production mode can't even recognize destructuring. It can only naively replace literal occurrence of process.env.NODE_ENV.

What is this? A f'ing template engine?

You wouldn't want to inject all of process.env, essentially giving away every single environment variable to the frontend. That's why it just looks up and replaces the reference exactly how it's defined, and only that specific variable.

I don't know how does it translate to exposing the whole env, I just assume generating global object literals constructed from DefinePlugins is easier than string.replace.

@vicary Creating an object that contains only the referenced variables would require analyzing the code, and probably break it down using ASTs and what not (I'm not an expert in the area). If anything goes wrong there a secret environment variable could potentially leak. Also, just referencing the env variable using process.env.VAR isn't really that big of a deal imo, especially when you consider that it saves build time and your ass. Having just a simple find and replace makes it clear what's actually being used.

Also, use @mentions so that people get notifications when you reply :)

@ScriptCoded Deducing dynamic keying is an uncomputable task, but for as long as you only use literal keys, consts assigned to literals and destructuring, it should be fairly simple and all of those would enable neat patterns. But otherwise I agree.

@ScriptCoded we assert required env vars from middlewares, which reads keys from JSON config files, just a sane test and nothing magic.

webpack should be able to add these as global constant object literals, it just needs change the way they process DefinePlugins, before TerserPlugin takes place.

So in theory this is trivial, of cause this may be a breaking change of people invented things replied on the current behavior, but still trivial.

For the leaking keys problem, when you literally have to write DefinePlugins for NODE_ENV, or just EnvironmentPlugin to do that for each variable you want to appear in the bundle, I don't think there are rooms for surprises buried in the existing mechanism of webpack config, except carelessness of cause.

@ScriptCoded to be very honest, this kind of literal replacements are not even build time macro magics, things are still happening in runtime.

When I look at expressions like `if ("production" === "production")` in output bundles I just can't help myself but getting depressed on what the modern internet is running itself upon.

@vicary ldflags in go then? Horrible as well? But I mean, if you have the solution, go make a PR. As you said, it's trivial.

@ScriptCoded I don't waste my time in huge projects because pushing through a change means lots of credibility build up and also work my way up to get the "contributor" tag to even have people replying.

People is people. Nash equilibrium forces me to pay as much effort as every other one of them to make a change as trivial as this one.

If I have to choose I'd rather make PRs to esbuild than webpack.

And this is where the niche of devrant comes in, when you don't want to waste your life to make a real change you can only rant.

@vicary Sure, I don't agree, but sure

@ScriptCoded You can keep all the faith in humanity, just let me air it out.