Change to `process?.env?.NODE_ENV`?

[FezVrasta]

In order to make the ESM builds work on modern browsers, without additional bundlers involved, would you consider change the way process.env.NODE_ENV is accessed to gracefully handle a missing process?

process?.env?.NODE_ENV or maybe process?.env.NODE_ENV should be enough.

[taion]

Wouldn't that defeat the point, though? The idea is for the check to be compiled out, such that we end up with the code removed through DCE. If process.env.NODE_ENV isn't getting compiled out, then you're better off not using this plugin.

[mmulet]

I'm running into this issue as well, but I agree with @taion. I think this may be better solved with a different, but similar plugin.

[mmulet]

Made a fork for it: babel-plugin-web-dev-expression

[taion]

Well, hold on a sec. I feel like I'm missing something here.

If you look at e.g., the point of something like https://github.com/4Catalyzer/babel-plugin-dev-expression#invariant is to result in better production code after going through a minifier that does dead code elimination.

If you're distributing code as-is, then it seems like you wouldn't want this.

It seems a little odd to run code that has gone through this transform in the browser without an additional DCE step, but I'm probably just missing something?

[mmulet]

I think there is some sort of impedance mismatch between people consuming esm directly in the browser and people using esm as input to a bundler (or similar). Some tools say they support esm, but it’s the latter not the former. The point is, it introduces an incompatibility with the browser even if its intended purpose is to be used with the browser.

[agilgur5]

Yea I'll agree with @taion that the browser ESM use-case should use a production minified bundle (like I mentioned in jaredpalmer/tsdx#631 (comment)), which would have process.env.NODE_ENV replaced and then DCE'd. The browser ESM use-case is quite different from the Node/bundler use-case.