[cli] Removing VERCEL_ENV in vercel@34.2.0 is a breaking change

[lirbank]

Our app depends on the VERCEL_ENV="development" to be set in local dev mode.

Publishing the change as a minor change breaks a lot of things. I think it should had been released as a major (breaking) change.

It is really convenient to have access to VERCEL_ENV in dev mode. I vote for adding it back.

Workaround: For now we have locked the cli to vercel@34.1.14 to fix it, eg vercel@34.1.14 env pull.

I am a big fan of Vercel, keep up the good work!

Ref

• https://github.com/vercel/vercel/releases/tag/vercel%4034.2.0
• [cli] Don't pull system environment vars in dev #11526

[mass8326]

Running into this as well using SvelteKit!

Environment variables are statically replaced when imported from $env/static/private and $env/static/public, so I was no longer able to build.

My solution for now is to create a .env file next to the .env.local file that vercel env pull generates. This is because SvelteKit uses Vite and its cascading env files. Fill it with placeholder values for whatever variables you need, check it into git, and then you're good to go.

You can alternatively make a .env.development specifically for svelte-check and a .env.production for vite build.

[onsclom]

I'm sorry this broke your builds! Can you tell me more about how you depend on VERCEL_ENV? Could you manually create your own environment variables and use those to accomplish the same things?

My thinking is that it is more consistent to just not have any system environment variables in local dev. Most of them have meaningless values, and the ones that do have meaningful values can be replicated through other means.

[lirbank]

If you remove VERCEL_ENV from dev, then this statement is not true anymore:

https://vercel.com/docs/projects/environment-variables/system-environment-variables#system-environment-variables

There are ways to work around it, I am just pointing out that it's a breaking change since the docs say it will be either of those three values.

Here is one of many example of how we use it:

// https://vercel.com/docs/projects/environment-variables/system-environment-variables
const production = "https://example.com"; // The production domain
const development = "http://localhost:3000";
const preview = `https://${process.env.VERCEL_URL}`;

export function getOrigin() {
  if (process.env.VERCEL_ENV === "production") {
    return new URL(production).origin;
  }

  if (process.env.VERCEL_ENV === "development") {
    return new URL(development).origin;
  }

  if (process.env.VERCEL_ENV === "preview") {
    return new URL(preview).origin;
  }

  // This should never happen
  throw new Error("Unknown origin");
}

In this example, I can just rearrange the code so that it falls back to development. But I need to think it through thoroughly, what if it is in CI/test mode? With the code as-is, I know it will barf if I screw up the test runner config etc.

Another use case is that we want to use a local Postgres DB for dev, which uses a different driver than Vercel Postgres or Neon Postgres, so we check VERCEL_ENV to use the right driver depending in environment. Again, I can change the code, but you are breaking a lot of stuff by removing the VERCEL_ENV for dev.

I think it is really convenient to have VERCEL_ENV available, as a complement to NODE_ENV. I think it is a mistake to remove it for dev.

[PonomareVlad]

@onsclom Let's remove VERCEL_ENV from .env but leave it at least in process.env ?

if this can be handled on vercel dev side ...