Usage of import.meta.env

[damianstasik]

I've noticed a small issue with how the (import.meta.env ? import.meta.env.MODE : undefined) condition is processed in code built by Vite. In short, import.meta.env in this condition gets replaced by a reference to an object containing all environment variables. Here's a snippet from a fresh Vite app using zustand:

var Bd = { BASE_URL: "/", MODE: "production", DEV: !1, PROD: !0, SSR: !1 };
const Ki = (e) => {
  let n;
  const t = new Set(),
    r = (v, m) => {
      const p = typeof v == "function" ? v(n) : v;
      if (!Object.is(p, n)) {
        const g = n;
        (n =
          m ?? (typeof p != "object" || p === null)
            ? p
            : Object.assign({}, n, p)),
          t.forEach((w) => w(n, g));
      }
    },
    l = () => n,
    s = {
      setState: r,
      getState: l,
      getInitialState: () => c,
      subscribe: (v) => (t.add(v), () => t.delete(v)),
      destroy: () => {
        (Bd ? "production" : void 0) !== "production" &&
          console.warn(
            "[DEPRECATED] The `destroy` method will be unsupported in a future version. Instead use unsubscribe function returned by subscribe. Everything will be garbage-collected if store is garbage-collected."
          ),
          t.clear();
      },
    },
    c = (n = e(r, l, s));
  return s;
};

As you can see, the condition and the warning are still present even though the code was built with MODE: "production". For some apps, this might not be an issue, but if you have many environment variables or some very long ones, it could be problematic. Depending on how many zustand modules end up in the bundle, you can get 4-5 of these objects, and each will contain all environment variables.

Would you consider using only process.env.NODE_ENV to check the environment? Most tools support it out of the box, whereas import.meta.env is a Vite-specific feature, though I wish it were standard.

[dai-shi]

Thanks for reporting! I was skeptical about it, but nobody has reported until now...
This applies to jotai and valtio too.

Does (!!import.meta.env ? import.meta.env.MODE : undefined) help by chance?

process isn't available for all environments, so we can't depend on it. Yeah, I wish there were a standard.

[damianstasik]

Does (!!import.meta.env ? import.meta.env.MODE : undefined) help by chance?

@dai-shi unfortunately no, I've tried a couple of things before reporting, but nothing works. I've also found that this behavior is deliberate on ESBuild’s part – here's a snippet from its changelog when the define feature was extended to support arrays and objects:

In this case a separate virtual file is created and configured to be injected into all files similar to how the --inject feature works. This means there is only at most one copy of the value in a given output file. However, these values do not participate in constant folding and dead code elimination, since the object can now potentially be mutated at run-time.

While I understand the mutation issue, I wish there was a way to force a different behavior. For example, back in 2021 Evan implemented an optimization to "minify property accesses on object literals", so if we had a say in how these define identifiers are inserted, this:

var Bd = { BASE_URL: "/", MODE: "production", DEV: !1, PROD: !0, SSR: !1 };
(Bd ? "production" : void 0) !== "production" &&
  console.warn(
    "[DEPRECATED] The `destroy` method will be unsupported in a future version. Instead use unsubscribe function returned by subscribe. Everything will be garbage-collected if store is garbage-collected."
  )

... would instead be:

({ BASE_URL: "/", MODE: "production", DEV: !1, PROD: !0, SSR: !1 } ? "production" : void 0) !== "production" &&
  console.warn(
    "[DEPRECATED] The `destroy` method will be unsupported in a future version. Instead use unsubscribe function returned by subscribe. Everything will be garbage-collected if store is garbage-collected."
  )

and then completely DCE-d.

process isn't available for all environments

That's true, although most packages seem to adopt it anyway. For example, React Router expects you to run it through a pipeline that inserts the proper environment name:

[dai-shi]

process isn't available for all environments

If we were to give up some envs, we could simply do import.meta.env.MODE !== 'production'. Non-vite bundler users can replace the custom string import.meta.env.MODE. Oh, but it may fail in Node.js... I wonder if Vite can replace import.meta.env?.MODE?? (Or, it would have been import.meta.ENV_MODE. 😢 )

[dai-shi]

How about adding import.meta.env ||= {}; at the top?

[timwuhaotian]

Not too deep into the topic, but since we've experienced it as well, It is because vite is checking bare import from this line?
https://github.com/vitejs/vite/blob/89eea020a3723276495b950542e1c71f4ced781a/packages/vite/src/node/plugins/define.ts#L167

I think possible side effect is when there are github env vars/secrets prefixed VITE_ (although secrets should use runtime or custom prefix), even though they are not used in actual bundle, but in this case, they will be attached/exposed in the bundle/client side.

[dai-shi]

https://vite.dev/guide/env-and-mode

To prevent accidentally leaking env variables to the client, only variables prefixed with VITE_ are exposed to your Vite-processed code. e.g. for the following env variables:

Can't we assume that adding VITE_ prefix means to expose it in the client bundle?