import.meta.env syntax caused runtime error

[sbaway]

dependence

• babel-preset-vite 1.0.3:
• @babel/core 7.13.14:

Relevant code or config:

const ENV_NAME = getConfigFileName(import.meta.env);

What you did:

npm run serve

What happened:

caused error
index.js:3375 Uncaught TypeError: Cannot read property 'VITE_GLOB_APP_SHORT_NAME' of undefined
    at getConfigFileName (getConfigFileName.ts?3133:6)
    at getAppEnvConfig (env.ts?9b7a:18)
    at getCommonStoragePrefix (env.ts?9b7a:7)
    at getStorageShortName (env.ts?9b7a:14)
    at createOptions (index.ts?e44f:13)
    at eval (index.ts?e44f:18)
    at Module../src/utils/cache/index.ts (index.js:1448)
    at __webpack_require__ (index.js:3372)
    at fn (index.js:3686)
    at eval (locale.ts:19)

when i changed code like this, project start without error

const ENV_NAME = getConfigFileName(process.env);

[mpeyper]

Hi @ColorfulCow,

Could you please test if this works?

const ENV_NAME = getConfigFileName({
  VITE_GLOB_APP_SHORT_NAME: import.meta.env.VITE_GLOB_APP_SHORT_NAME
});

I've got a theory that the way we identify which variables replace relies on us knowing which variable you're accessing, but as you're passing it into the function, we lose the link. The main reason it was built this way instead of just replacing import.meta.env with process.env was because of some of the restrictions their docs specify when using this value:

1. Only VITE_... variables get exposed on top of the built in variables
2. The values get statically replaced for production builds so certain kinds of accesses are not permitted

Given I assume your code looks something like:

function getConfigFileName(env) {
  return env.VITE_GLOB_APP_SHORT_NAME;
}

// ...

const ENV_NAME = getConfigFileName(import.meta.env);

I wonder if you're in violation of the second point as I don't know how Vite could statically replace that reference to VITE_GLOB_APP_SHORT_NAME? Have you seen it working in a production build?

I also wonder what the expected thing to happen here is. We could replace it with an empty object instead of undefined?

To fix the issue we would need to replace it with an object containing the built in variables and any process.env values starting with VITE_, but I'm not sure that's actually correct.

[mpeyper]

Ok, so after a quick test I can confirm that their docs are a bit misleading and the usage in the issue does work, as does the irregular access (import.meta.env[key]) they said does not work. It does statically replace the standard access of the variables, but when it cant work it out, the whole import.meta.env value with an object as I described at the end of my last comment, e.g.

console.log("normal usage", import.meta.env.VITE_TEST_VALUE)

console.log("irregular usage", import.meta.env["VITE_TEST_VALUE"])

const key = "TEST_VALUE"
console.log("irregular usage 2", import.meta.env[`VITE_${key}`])

function printTestValue(env: Record<string, unknown>) {
  console.log("normal function:", env.VITE_TEST_VALUE)
}

printTestValue(import.meta.env)

function printSomeValue(env: Record<string, unknown>, key: string) {
  console.log("irregular function:", env[key])
}

printSomeValue(import.meta.env, "VITE_TEST_VALUE")

gets output as (with minification disabled):

console.log("normal usage", "yes");
console.log("irregular usage", {VITE_TEST_VALUE: "yes", BASE_URL: "/", MODE: "production", DEV: false, PROD: true}["VITE_TEST_VALUE"]);
const key = "TEST_VALUE";
console.log("irregular usage 2", {VITE_TEST_VALUE: "yes", BASE_URL: "/", MODE: "production", DEV: false, PROD: true}[`VITE_${key}`]);
function printTestValue(env) {
  console.log("normal function:", env.VITE_TEST_VALUE);
}
printTestValue({VITE_TEST_VALUE: "yes", BASE_URL: "/", MODE: "production", DEV: false, PROD: true});
function printSomeValue(env, key2) {
  console.log("irregular function:", env[key2]);
}
printSomeValue({VITE_TEST_VALUE: "yes", BASE_URL: "/", MODE: "production", DEV: false, PROD: true}, "VITE_TEST_VALUE");

I'll update the plugin to support this in the same way (i.e. single value replacement where we can, full object replacement where we can't).

[github-actions]

🎉 This issue has been resolved in version 1.0.4 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 1.0.3 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This issue has been resolved in version 1.1.0 🎉

The release is available on npm package (@latest dist-tag)

Your semantic-release bot 📦🚀