firebase-tools: Conflict between package.json `engines` field's purpose and use

First off, I read https://github.com/firebase/firebase-tools/issues/1038 and I totally agree with the goal of having a fixed and reproducible runtime version, pretty much the same reason lockfiles are a must-have. I ran into the same issue and, unfortunately, there doesn’t seem to be an easy bypass on my end.

Environment info

firebase-tools 7.0.2 Linux

Test case / Steps to reproduce

You’ll need:

• A project that need to deploy a firebase cloud function
• A node version on the current machine that is different from the targeted runtime for the function
• To use yarn to manage your deps

Either set engines to a valid firebase node version (say… {"node": "8"}) and run yarn to install your deps, or set engines to what your package really runs in and run firebase deploy.

Expected behavior

I need a way to both:

• Tell firebase what runtime the function should run in. It should be a single well-defined version that doesn’t need to be installed on my computer.
• Tell yarn what versions of node this package can run in. It should be a range and my computer must have it, the firebase target runtime must be in that range (although I don’t really see a reason to check).

Actual behavior

If you set a valid firebase runtime version in the engines field of your package.json, run yarn to install your deps:

The engine "node" is incompatible with this module. Expected version "8". Got "11.15.0"

If you set a node version that matches what’s on your machines/farms, run yarn to install your deps, then run firebase deploy and you get (I put {"node": ">=11"}):

Error: package.json in functions directory has an engines field which is unsupported. The only valid choices are: {"node": "8"} and {"node": "10"}. Note that Node.js 6 is now deprecated.

Bypassing the issue

The issue could be bypassed previously by setting the engines field to the desired version, deploying the function once, and then removing the field. Firebase would then keep using the same version as what was deployed, not ideal but it worked. I could revert to an older version of the tool and shrug it off for now, but it will break eventually.

I could run yarn config set ignore-engines true on all affected machines. That check has been useful in the past though, so not ideal either.

It’s possible to patch the package.json just before deploying and set the engines field to a value firebase will accept. Probably what I’m going to do for now.

Proposed solution

Would it be possible to set the target runtime version in firebase.json in the functions section? Would it work for you? src/runtimeChoiceSelector.ts seem to be what handles this and changing the behavior + handling compat seems possible, not sure where the doc is though, but this looks like the page to update.