Can't use arbitrary value as Vite mode to build non-production code

[yegorius]

Environment info

firebase-tools: 13.16.0

Platform: Linux

Test case

Any Vite based project which uses modes.

Steps to reproduce

We disable AppCheck in local dev environments. We only enable it in prod or staging environments.

if (!dev) initializeAppCheck();

We also store FB configs in .env files for prod and staging FB projects (.env.production and .env.development). Building production code is fine, firebase deploy calls vite build --mode production by default. But how do we build staging code? I checked the code of firebase-tools and it seems we can use FIREBASE_FRAMEWORKS_BUILD_TARGET to override build target, so let's set it to development. Now comes the problem: when FIREBASE_FRAMEWORKS_BUILD_TARGET is set to development it also causes NODE_ENV to be development which, in its own turn, causes dev from $app/environment to be true (SvelteKit uses benmccann/esm-env). So now we have code built for staging env with dev set to true. OK, let's try setting FIREBASE_FRAMEWORKS_BUILD_TARGET to staging. Unfortunately it's not possible because this variable only supports two values production and development and firebase deploy bails out if anything else is supplied. Eventually, we might find a workaround by once again monkey-patching src/frameworks/vite/index.ts but the problem is wider. What if someone has multiple Vite modes like: production-us, production-eu, staging-us and staging-eu? How do we pass arbitrary values to vite build --mode? Or what if someone has additional build step after the code is built but before it's deployed? The problem here is that firebase deploy not only deploys, but also builds the code. It tries to do this auto-magically. And while doing so it takes away some freedom from the developers. After many rounds of discussions and patches, It might, eventually, get it right, but this is going to be another layer of abstraction to deal with. My proposal is simple: don't build the code in firebase deploy. Let developers build the code correctly and just deploy it. It's a win-win situation: firebase-tools devs have less work to do, and fb-tools users have less things to figure out. As in Unix philosophy:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

Expected behavior

dev is false

Actual behavior

dev is true

[plungarini]

Same here. +1

[leoortizz]

Hey @yegorius, thanks for reporting your issue. In this case you should be able to use a parameterized configuration to achieve your goal. Please take a look at this comment: https://github.com/firebase/firebase-tools/issues/7207#issuecomment-2168321754 which is related to a similar issue.

In this case you should modify your .env files to be named with the related project ids.

Let me know if that solves your main issue.

[yegorius]

We have moved this service to Cloud Run, but looking at the documentation, parametrized configuration could have solved this for us, although I would still prefer to be able to pass Vite mode or firebase deploy not to build the project.