$ npm install
...
3 vulnerabilities (2 low, 1 high)

To address all issues, run:
  npm audit fix

...
26 vulnerabilities (22 moderate, 4 high)

That looks BAD.

The bar for this library's production releases is:

• no high vulnerabilities

If they are in libraries, we should wait until those are resolved.

Let's see where they arise:

The list is so long and cryptic, I'm not placing it here...

Firebase MAY HAVE A SERIOUS (ATTITUDE?) PROBLEM WITH NODE AUDITS and if you dislike that, going to another serverless stack may be the only option. The name of the library has firebase in it, so we're kind of stuck/doomed... 🦤

$ npm list ajv
@local/root@
└─┬ firebase-tools@10.2.0
  ├─┬ @eslint/eslintrc@1.0.5 extraneous
  │ └── ajv@6.12.6 deduped
  ├── ajv@6.12.6
  ├─┬ better-ajv-errors@0.6.7 extraneous
  │ └── ajv@6.12.6 deduped
  ├─┬ eslint@8.6.0 extraneous
  │ └── ajv@6.12.6 deduped
  ├─┬ exegesis@4.1.0
  │ ├─┬ ajv-formats@2.1.1
  │ │ └── ajv@8.8.2
  │ └── ajv@8.8.2
  ├─┬ oas-validator@4.0.8 extraneous
  │ └── ajv@5.5.2 extraneous
  └─┬ request@2.88.2
    └─┬ har-validator@5.1.3
      └── ajv@6.12.6 deduped

See below

$ npm list jsonpointer
@local/root@
└─┬ firebase-tools@10.2.0
  ├─┬ atlassian-openapi@1.0.13 extraneous
  │ └── jsonpointer@4.1.0 deduped
  ├─┬ better-ajv-errors@0.6.7 extraneous
  │ └── jsonpointer@4.1.0 deduped
  └── jsonpointer@4.1.0 extraneous

See below

Why would firebase-tools bring mocha to deployment??

$ npm list nanoid
@local/root@
└─┬ firebase-tools@10.2.0
  ├─┬ mocha@9.1.3 extraneous
  │ └── nanoid@3.1.25 deduped
  └── nanoid@3.1.25 extraneous

We can contain firebase-tools within a Docker VM (see firebase-ci-builder), but the author doesn't wish to make Docker a build dependency. It is an option, though...

By using demo-... project id, the Firebase Emulators are told that the project is to be run offline.

A wholly different scenario is what your Cloud Functions might do, under the hood of the emulator.

This is not in the hands of Firebase, since you might access third party APIs from within there.

Be reasonable. This project is not giving you a sample on how to cope with this approach.

Ideas (since obviously I cannot shut up!):

• With Docker compose, one can set up an environment that restricts access to the Internet (it's essentially a proxy). One could then white list addresses that the tests are allowed to access, while blocking others.
• This could be beneficial also for not allowing newer images to be loaded, which is something the Firebase Emulators insist on doing (they don't have a global "really, offline!" switch)

The author doesn't see this as valuable enough to develop right now. Samples on how to reach it are welcome, if you did.