Simpler Firebase Deployment Strategy

[ih84ds]

First of all, THANK YOU SO MUCH for making this package! I was pulling my hair out trying to find an elegant solution for not being able to maintain package isolation in my yarn workspaces monorepo.

I believe I have a simpler approach for deploying firebase functions than the one that is laid out here. This strategy allows you to preserve "live code updates" and allows firebase.json to remain unmodified.

Instead of setting "source": "./isolate", you can do deployment using a script like this in the package.json of your workspace package:

  "scripts": {
    "deploy": "isolate && firebase --config isolate/firebase.json deploy",
  }

This takes advantage of firebase.json being copied into ./isolate. That way, it will deploy from the source relative to that firebase.json. Meanwhile, local dev emulators remain unaffected by the isolate stuff. 🙌

I appreciate the fact that firebase-tools-with-isolate exists, but I don't want my project(s) to be dependent on a fork that may or may not have all of the latest upstream changes merged.

[0x80]

Thanks, that's a great idea! I'll look into it.

Of course I would also prefer not having to maintain firebase-tools-with-isolate 😄

[0x80]

@ih84ds I could use a bit more info on how you managed to deploy it.

I tried to apply your strategy, but I get the following error when I try to deploy:

Error: Failed to find location of Firebase Functions SDK. Please file a bug on Github (https://github.com/firebase/firebase-tools/).

The problem seems to be that when executing the firebase deploy command, it tries to find the firebase-functions binary in the node_modules folder relative to the "source" setting. See code here

So in my case it would be looking for node_modules inside of the isolate directory.

[ih84ds]

Whoops. Did you mean upgrading from 1.20.0 to 1.23.0-0? Because 1.2 would be pretty old...

D'oh. Yep, 1.20.0!

1.22 was supposed to handle tsconfig with extends which would prevent the outDir error if outDir was defined by the extended config.

I'm using extends without issue in 1.20.0 🤔

My own projects seem to have no problem deploying with firebase-tools-with-isolate@13.29.1 (which uses isolate-package@1.22.0) or isolate-package@1.22.0 separately.

I'm not using firebase-tools-with-isolate (which was the reason I opened this discussion -- to point on that it works great without it).

Here is my tsconfig.json in my backend package, FWIW:

{
  "extends": "../../tsconfig.base.json",
  "files": [],
  "include": [],
  "references": [
    {
      "path": "../entities"
    },
    {
      "path": "./tsconfig.lib.json"
    }
  ]
}

[ih84ds]

Ohh, actually, I forgot that I configured tsconfigPath: "tsconfig.lib.json". Here is that one:

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "baseUrl": ".",
    "rootDir": "src",
    "outDir": "lib",
    "tsBuildInfoFile": "lib/tsconfig.lib.tsbuildinfo",
    "emitDeclarationOnly": false,
    "types": ["node"]
  },
  "include": ["src/**/*.ts"],
  "references": [
    {
      "path": "../entities/tsconfig.lib.json"
    }
  ],
  "exclude": ["jest.config.ts", "src/**/*.spec.ts", "src/**/*.test.ts"]
}

[ih84ds]

I got it working (on 1.23.0 today) with buildDirName: "lib" instead of setting tsconfigPath. I had overlooked that config option when initially setting things up. I actually like that better anyway. Simpler/less coupling. Sorry for the confusion! 🙌

If you want me to test anything else with my setup, just let me know.

[0x80]

I'm using extends without issue in 1.20.0 🤔

Extends was only problematic if the base config was the one defining the outDir, and your extended config didn't have it, because then isolate-package would think outDir was undefined.

With the use of get-tsconfig all properties should now resolve correctly.

[ih84ds]

With the use of get-tsconfig all properties should now resolve correctly.

That doesn't seem to be the case. It stopped working after that update for my tsconfig.lib.json above. But, I'm happier with the buildDirName solution anyway.

[0x80]

@ih84ds Today I managed to solve a long standing pain point. Now we are able to adhere to the officially recommended Firebase setup for monorepos. See the announcement here for more info.

I actually think this is the preferred approach, because it simplifies the configuration and most importantly allows you to run multiple firebase packages together in a single emulator setup. I don't think you can achieve this without the firebase-tools fork.

But likely I will still add support for your idea of deploying directly with isolate-package by copying the local firebase.json into the isolate output, because I think I already have the logic implemented in a branch...

[ih84ds]

But likely I will still add support for your idea of deploying directly with isolate-package by copying the local firebase.json into the isolate output, because I think I already have the logic implemented in a branch...

I'm confused because it's already doing this for me as-is.

I actually think this is the preferred approach, because it simplifies the configuration and most importantly allows you to run multiple firebase packages together in a single emulator setup. I don't think you can achieve this without the firebase-tools fork.

Ah, interesting! I hadn't run into that issue. I'm only running the emulators from from one single backend package at the moment. But I could see how that would be problematic for multiple backends that use firestore/pubsub/etc. Nice!

[0x80]

I'm confused because it's already doing this for me as-is.

I must have misunderstood you then. I thought you were copying the firebase.json config into the isolate directory yourself. So my plan was to have isolate-package handle the step of copying the config file to the isolate dir.

Also, if the firebase.json is instead located at the root of the monorepo, I wanted to make it so that it extracts the configuration for that particular functions package.

[0x80]

I don't think you can achieve this without the firebase-tools fork.

On second thought, I think this is probably not true. With the unified config in the root, I think it should be possible to use the normal firebase-tools for running the emulators, and then use your deployment strategy with isolate-package for deploying the individual packages.

Only you then need to remember to not use firebase deploy on the root, because it won't work. So I think for consistency and simplicity I would still prefer to use the fork.

BTW the fork doesn't really change the runtime workings of firebase-tools. It takes me about 5mins to sync it to upstream whenever they publish a new version.

It's unfortunate that NPM is not fully supported yet (lockfile versions do not match) otherwise I think they could have maybe considered it as an official solution.

[ih84ds]

I must have misunderstood you then. I thought you were copying the firebase.json config into the isolate directory yourself. So my plan was to have isolate-package handle the step of copying the config file to the isolate dir.

Ah, nope. The isolate script was/is copying everything (including firebase.json) into the isolate dir already.

Also, if the firebase.json is instead located at the root of the monorepo, I wanted to make it so that it extracts the configuration for that particular functions package.

I'm having trouble understanding how this could work in the general case. I guess you'd be constrained to only having deployable functions in one of the packages, and you'd have to do some fancy path translation to get the isolated deployment to work.

[0x80]

Ah, nope. The isolate script was/is copying everything (including firebase.json) into the isolate dir already.

Ah yes you can of course just add it to the files property in your manifest, and then it'll get picked up by the isolate process.

I'm having trouble understanding how this could work in the general case.

In the root configuration you'd have "functions" as an array of configurations. Each has its "source" pointing to the deployable packages.

So when isolate runs, is just looks up the corresponding functions configuration from firebase.json based on the target package folder name, and inject the result to a local firebase.json file and overwrite "source" to be "."

See this for more info https://firebase.google.com/docs/functions/organize-functions?gen=2nd#managing_multiple_source_packages_monorepo