Create an InternalExpression type which allows precanned access to env.FIREBASE_CONFIG

[Berlioz]

Defines special Expressions that users can import from firebase-functions/params that pull a value out of process.env.FIREBASE_CONFIG, but are never prompted for. Pairs with firebase/firebase-tools#4970.

[taeold]

Should this be marked @hidden or @beta or @Alpha or whatever so we don't expose it to our end user?

I wish we can use @internal, but I'm afraid that might break user code that tries to reference variables with that type 🤔

[inlined]

No, it should be @internal and the variable should be declared as an Expression. Type erasure is great for hiding implementation details and not tying our hands to them.

[Berlioz]

That's a good point. Done.

[inlined]

Unfortunately the part you're trying not to do is the part I specifically want to do. I want people to be able to say:

const bucket = defineResource("BUCKET", {
  input: {
    resourceSelector: { type: "storage.googleapis.com/Bucket" },
   },
   default: params.storageBucket,
});

That means you're going to need to support both a toCEL and a CEL parser for something like {{ params.FIREBASE_CONFIG.bucket }} in the CLI

[inlined]

Hmmm... on second thought I can see how (for now) you can turn that into literal values in the CEL expression?... there may be less work than anticipated (e.g. not extending the parser) but the user journey is what I'm hoping for.

[Berlioz]

It turns out that feature isn't difficult to support. Done.

[inlined]

I think your magic transformation of FIREBASE_CONFIG to params.DEFAULT_BUCKET et. al. might be on the right track. The extensions team is looking at adding a bunch of new expressions, and I think I've negotiated that they will not be published as environment variables (since we'll use up the user's list). So I think we should strongly consider having a list of magic envs in the CLI that we have values for but don't write to .env files. Everything you've done here is a good candidate.