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

[quentinvernot]

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.

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[samtstern]

I think @mbleigh was already working on something like this, thanks for filing such a detailed issue!

[quentinvernot]

@samtstern So uh... it's been a month, I kinda forgot, sorry. Patching the json just before the deploy works like a charm, but it would be nice not to have to do it for future projects.

Should I do a PR? Would you prefer supporting both methods (maybe with a warning when using the engines field in package.json) or dropping the other one altogether?

[samtstern]

@quentinvernot just to better understand, why do you want to declare a version >= 11 in your engines field but you are fine with deploying your Cloud Functions to a Node.js 8 environment? Wouldn't that imply that you're being too strict in engines?

[quentinvernot]

That's what I tried at first, the tool doesn't let me.

Edit: The error message is:

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.

/Edit

Like people said in #1038, if I put { "node": ">=8" }, firebase would need to guess what version I really want and could pick the wrong one + that would likely make the build non-reproducible. I'm totally ok with this choice, it's kinda like lockfiles, you want the exact version used to be written somewhere.

[samtstern]

@quentinvernot thanks for the extra context. I know the team is working on many things right now but hopefully @mbleigh or @bkendall or someone else will be able to get to this soon. I am not enough of a node expert to get this behavior right.

[jeremad]

Any progress on this one? Thank you very much

[GoMino]

we are using firebase functions in a yarn workspace monorepo, we cannot change the node js version used because of other packages in the monorepo.
The current behavior is a real limitation.

My current workaround the issue for now (thanks to npe), is using the following deploy script:

"deploy": "npe engines.node '8' && firebase deploy --only functions && npe engines.node '>=8'",

and set the following as a default in the package.json file:

"engines": {
    "node": ">=8"
  },

[mbleigh]

Thanks for the detailed report of why this is a problem. I'm proposing the following be allowed in firebase.json:

{
  "functions": {
    "runtime": "nodejs8" // or nodejs10
  }
}

This would supercede whatever is declared in the "engines" field in package.json and so would (I think) fix the issue. How does that sound to folks?

I need to get this approved through the internal API review process, and I'm not sure when exactly we'll be able to free someone up to implement. That being said, if anyone is feeling adventurous and wants to make a pull request, I'd be happy to take a look!

[GoMino]

Not sure I understand correctly, with your proposal would the engines field in the package.json file still be required ?

[mbleigh]

With my proposal if you specify runtime in firebase.json, the CLI wouldn't check or care about your engines field in package.json so you could leave it blank, set it to a range, whatever you want to do.

[GoMino]

Sounds good to me!

[quentinvernot]

Sounds perfect!

[quentinvernot]

PR sent: https://github.com/firebase/firebase-tools/pull/2241

[samtstern]

Closing this since #2241 was merged, thanks again @quentinvernot !

[quentinvernot]

Found a few minutes to use 8.6.0 on those projects where I use functions, works like a charm, thanks!