Find closest .firebaserc up a directory tree

[jthegedus]

It would be great if the logic for loading the .firebaserc looked up the directory tree similar to read-pkg-up.

This would save having to copy .firebaserc files across service folders in monorepo architectures.

currently:

- api/
|  - .firebaserc
|  - firebase.json
- app/
|  - .firebaserc
|  - firebase.json
- etc...

what this would allow:

- .firebaserc
- api/
|  - firebase.json
- app/
|  - firebase.json
- etc...

Related code:

• https://github.com/firebase/firebase-tools/blob/78f11b62ab658a5a59b291daad7ea5ee08b2bc34/src/command.js#L159
• https://github.com/firebase/firebase-tools/blob/78f11b62ab658a5a59b291daad7ea5ee08b2bc34/src/rc.js#L191

[bkendall]

an interesting idea, but I'm not sure it's one we'd tackle right away. PRs are always welcome, though!

[mbleigh]

Can you describe the contents of the firebase.json files in your monorepo? Typically I would expect a single firebase.json at the root of the structure and a single .firebaserc to go along with it. More info about your project structure would help me understand the use case :smile:

[jthegedus]

This is feature request is just a matter of convenience, not pressing at all.

More info about your project structure would help me understand the use case

Firebase w monorepos & microservices

Most monorepos for service/microservice oriented apps I've seen/developed split the app into domain-based services. In a monorepo architecture these are root level folders. To allow services to be deployed independently they each own their install/test/deploy/config etc. This also allows each service to be implemented using whichever technology the service owners wish, as long as they implement the standard install/test etc scripts. I've seen this done with AWS and often hear people use the fact that you must deploy all Cloud Functions at once, or that they all must be within the same folder, as a reason not to try Firebase. On the surface, it doesn't appear to scale well with larger teams and enforces a particular repo code structure. The following has been my attempt to prove otherwise. For services that are implemented on Firebase they all must have a`.firebaserc` and `firebase.json`. The `firebase.json` files must not have conflicting configs. The `.firebaserc` files need to be the same.

Can you describe the contents of the firebase.json files in your monorepo?

my example architecture

an example service that only has Cloud Functions: ``` +- dist/ # compiled code | | | +- index.js # CF entrypoint, defined by pkg.json "main" field | +- index.js.map # maps compiled to raw source in ../src/ +- node_modules/ # ignored by firebase-tools on upload +- src/ # raw source code | | | +- index. # entrypoint to compile +- .firebaserc # firebase project identification config +- firebase.json # folder to deploy (this folder) +- package.json # deps, entrypoint (main field) & npm scripts ``` and it's `firebase.json` contents: ```json { "functions": { "source": ".", "ignore": [".firebaserc", "firebase.json", "**/node_modules/**"] } } ``` Ways to make this easier to manage - Cloud Functions are deployed using Function Groups with a prefix equal to the service/group name. - Services with Hosting requirements must use their own site configuration (the addition of multiple sites let's us confine Hosting rules to particular domains and thus services). Issues with this type of repo structure: - `firebase.json` configs must not conflict. - `.firebaserc` duplication. A tool to combine and validate the `firebase.json` configs would be extremely useful here. It's something I have considered developing. I've spent my time working on this as a way to convince people of how they can scale Firebase with a "microservice" arhcitecture. Unfortunately, I hear "Firebase doesn't scale to larger teams" more often than I like. I'm yet to publish, and therefore recommend this approach on my blog. Interestingly, I find this architecture works very similar to the advances I am testing out in the Alpha program at the moment 😯 😉 I'm open to further discussion on this via email or whatnot.

[simondotm]

Can you describe the contents of the firebase.json files in your monorepo? Typically I would expect a single firebase.json at the root of the structure and a single .firebaserc to go along with it. More info about your project structure would help me understand the use case 😄

Here's a relevant use case I'm currently working with:

For a mono-repo that contains multiple firebase projects, I want to be able to robustly protect against a potential developer error of accidentally deploying the wrong functions to an incorrect target firebase project, which is tricky because it's only possible to have one .firebaserc file at the moment.

Further details:

In my (Nx) mono-repo workspace I've got multiple firebase projects in play - 2 separate firebase functions "applications" (project1 and project2), each with two environments (dev + prod), so 4 firebase projects all together - lets call them: project1-dev, project1-prod, project2-dev, and project2-prod.

All 4 firebase projects are set in the .firebaserc file in the workspace root as aliases with the same names.

Each of my two applications has its own firebase.<projectname>.json config in the root, which I can use to deploy as follows:

For project1: firebase deploy -P project1-dev --config firebase.project1.json --only functions OR firebase deploy -P project1-prod --config firebase.project1.json --only functions

For project2: firebase deploy -P project2-dev --config firebase.project2.json --only functions OR firebase deploy -P project2-prod --config firebase.project2.json --only functions

The significant risk here is that one day, a developer (possibly me!) might accidentally do this: firebase use project1-dev firebase deploy --config firebase.project2.json --only functions

Which is potential disaster because we've got project2's functions being deployed to project1, possibly overwriting existing functions. The CLI might warn "some functions exist on the cloud not in your project" etc. but if there are similar named functions it might not.

I'm not sure yet if making .firebaserc tree relative (as per OP suggestion) will solve my specific issue. However, in my case, being able to specify a .firebaserc file in the firebase.json config (or possibly even as a CLI parameter) would be helpful also. This way we have some means to prevent deployment to an invalid target in scenarios where there are multiple firebase projects in play.