-
Notifications
You must be signed in to change notification settings - Fork 936
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find closest .firebaserc up a directory tree #1116
Comments
an interesting idea, but I'm not sure it's one we'd tackle right away. PRs are always welcome, though! |
Can you describe the contents of the |
This is feature request is just a matter of convenience, not pressing at all.
Firebase w monorepos & microservicesMost 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
my example architecturean example service that only has Cloud Functions:
and it's {
"functions": {
"source": ".",
"ignore": [".firebaserc", "firebase.json", "**/node_modules/**"]
}
} Ways to make this easier to manage
Issues with this type of repo structure:
A tool to combine and validate the 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. |
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 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: All 4 firebase projects are set in the Each of my two applications has its own For project1: For project2: The significant risk here is that one day, a developer (possibly me!) might accidentally do this: 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 |
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:
what this would allow:
Related code:
firebase-tools/src/command.js
Line 159 in 78f11b6
firebase-tools/src/rc.js
Line 191 in 78f11b6
The text was updated successfully, but these errors were encountered: