firebase cli cannot deploy functions when using pnpm, turborepo along with firebase-functions@4.0.0

See original GitHub issue

Environment info

firebase-tools: v11.15.0 firebase-functions: v4.0.1

Platform: macos (local dev), ubuntu (ci)

Test case

Steps to reproduce

Deploy firebase functions for nodejs with firebase-tools and firebase-functions versions noted above.

Expected behavior

Cloud functions deploy successfully

Actual behavior

Firebase functions triggers are not parsed, resulting in no functions being deployed. If you are using the --force flag, your functions will be deleted.

tldr; I upgraded from firebase-functions@3.24.1 to firebase-functions@4.0.1, resulting in my function triggers not being parsed and all my firebase functions being deleted (and an outage for our customers 🔥). I think firebase-tools should prevent users from deploying with firebase-functions@4

I thought it was safe for me to upgrade to firebase-functions@v4 as their release notes did not mention any incompatibility with the current version of firebase-tools. Upon upgrading my CI did a deploy, deleting all my functions.

The cause is that my function triggers were no longer recognised by firebase-tools, and I have set my CI to deploy with --force, resulting in no functions deployed and all my functions being deleted.

I traced the source of the issue, being that firebase-functions@v4 no longer adds __trigger to the cloud functions triggers, but firebase-tools uses this property to discover function triggers in extractTriggers.js. This is mentioned in the release notes for firebase-functions “Removed __trigger object on function handlers.”, although it’s not immediately obvious that means that function triggers will no longer be recognised at all.

I did notice that the peerDependencies of firebase-tools does not allow firebase-functions@4 but unfortunately my tools did not prevent the upgrade (I accepted the upgrade from renovate bot after reading the release notes and deeming it a safe upgrade).

I would like to suggest that my issue could have been avoided if firebase-tools prevented users from deploying with firebase-functions@v4. There is already a check to make sure an incompatible (lower) version of firebase-functions is not used.

Issue Analytics

State:
Created a year ago
Reactions:9
Comments:10 (5 by maintainers)

Top GitHub Comments

1reaction

mpsqcommented, Oct 25, 2022

Same issue with npm workspaces.

0reactions

MarcPorciunculacommented, Nov 7, 2022

Hi @taeold, before deploying to Cloud Functions for Firebase we bundle our source code into a format more close to a typical npm setup. This is the only way we’ve been able to reliably deploy to Cloud Functions for Firebase, and we used to use a similar mechanism when we previously used yarn (classic) and yarn (2.x, 3.x).

For context, one of the the main reasons we use a pnpm monorepo setup is so we can share code by making packages that are not published to the registry, but are referenced and linked locally by pnpm (workspace dependencies, which use a workspace:* version specifier). To get a Cloud Functions for Firebase package to deploy, we use a special bundling and deployment process that emulates a regular single package npm setup.

Bundling process:

Regular rollup stuff including compiling typescript and bundling individual modules into one (or few) files. We keep any npm dependencies external as we find bundling them in can have unintended runtime effects.
Bundle in any workspace dependencies so we don’t need to depend on them at runtime (we can’t anyway because they are not published to a registry).
In the build output, we create copy of the package.json
- We remove all dev dependencies, as Cloud Build does a production only install when we deploy.
- We remove all workspace dependencies, as they have already been bundled in.
- We add all transitive dependencies found through all workspace dependencies.

The result is a self contained package that can be deployed to Cloud Functions for Firebase. Note this output package does not contain any references to the rest of the monorepo.

Deployment process:

We point functions.source in firebase.json to the build output folder.
We run pnpm install --shamefully-hoist inside the build output folder, this installs dependencies in a folder structure that is (mostly) equivalent to an npm or yarn install.
- We have to do this so that all dependencies are present when when we run firebase deploy, otherwise loading the code for trigger parsing can crash.
- This is also a dry run for the npm install that will be performed by Cloud Build, as the Node.js Cloud Functions buildpack does not have support for pnpm.
We run firebase deploy --only functions:<namespace> in the main package.

Here is an example of the file structure for context.

- node_modules/ (uses the pnpm node_modules structure with symlinks to workspace packages in the monorepo)
- package.json (makes use of workspace:* specifiers only available in a monorepo)
- firebase.json (functions.source is set to 'dist/')
- src/
  - index.ts
- dist/
  - node_modules/ (installed at deploy time using pnpm install --shamefully-hoist)
  - package.json (normal package.json usable by npm)
  - index.js (includes bundled in code from other workspace packages)

Let me know if I can provide anything further.

FYI I noticed there are a few other tools being mentioned in this thread, to be clear my setup only uses pnpm, the notable differences from a regular npm setup being the use of workspace dependencies and the node_modules folder structure used by pnpm. I am not using turborepo, nx, or any other monorepo build tool.