I found that when I have a firestore running on local emulator, and I want to directly access it with a script using the admin SDK, I need to supply the project-id to the admin SDK, which I believe is not the intended behavior.
I use the nodejs firebase-admin package, not sure if the bug is theirs.
firebase-tools:
8.10.0
npm firebase-admin package
9.1.1
Platform:
Windows
see below
test.js locally:const admin = require('firebase-admin');
admin.initializeApp();
admin.firestore().collection('foo').add({ a: 1 });
$ FIRESTORE_EMULATOR_HOST="localhost:8080" node test.js
should see a document created in the emulator firestore UI
Error: Unable to detect a Project Id in the current environment.
To fix this, I need to supply the project id to the admin SDK:
admin.initializeApp({ projectId: 'my-project-id' }); // now works
But I believe it's not the intended behavior.
try
const firebase = require('@firebase/testing');
const MY_PROJECT_ID = 'my-project';
function getAdminFirestore() {
return firebase.initializeAdminApp({ projectId: MY_PROJECT_ID }).firestore();
}
Hi @markgoho , thanks, your snippet was the same as mine (at the bottom of my post).
The issue is not getting it to work, the issue is that project-id shouldn't be required. This code is very likely for the purpose of unit testing, and 1. I may change the project id with firebase use, and 2. I may not want to commit my project-id into source control for open source projects, which is why .firebaserc is a separate file from firebase.json.
@ZYinMD this is the intended behavior, without some project ID (does not have to be a real one!) the Firestore Admin SDK can't construct the right calls to the Firestore API, or in this case the Firestore Emulator.
If you want to set this without modifying source code, use the GCLOUD_PROJECT environment variable which is respected by all Cloud SDKs.
Hi @samtstern , thanks! Should it be mentioned in the doc here?
Also, about "project ID doesn't need to be a real one" that you mentioned: I tried to set it to 'foo', and indeed, it still works, which blew my mind. Should it also be mentioned in the doc?
@ZYinMD I will update the docs, thanks!
@ZYinMD just FYI if you're using the Firestore and Functions emulators together make sure they have the same project ID! Otherwise triggers won't fire, etc.
@samtstern to clarify: the emulator reads the real project-id from .firebaserc, and the admin-sdk running with the functions is also part of the emulator, which also reads the same project-id, which has no issues. However, the admin-sdk in the test suites mentioned in the OP is manually given a project-id, and you're saying this one should also be the same one, which is the real id, correct?
@ZYinMD sorry for the slow response but yes that's exactly it.
@samtstern If you could also add a single line code to that documentation, that would be very nice. like:
admin.initializeApp({ projectId: 'my-project-id' });
@vajahath will do!
Hi @samtstern, I see that you have updated the doc since the discussion above.
I just found that using a fake project-id has more problems than I thought - the documents inserted into the db with a fake project-id won't show up in the emulator UI, which means the setup of a fake-project id + admin-sdk + emulator for prototyping is pointless.
You might want to make it more clear in the doc, the way it's written now is a little misleading because it advertises something that sounds great, but don't really work.
It's also worth noting that this setup is still usable in unit testing, because the tests don't involve the emulator UI. However, the test becomes flaky when it involves both directly accessing the db and accessing the db via functions, because the functions will always use the real project-id stored in firebaserc.
@ZYinMD we're working on showing multiple databases in the Firestore Emulator UI, you can follow that here:
https://github.com/firebase/firebase-tools-ui/issues/281
Most helpful comment
Hi @markgoho , thanks, your snippet was the same as mine (at the bottom of my post).
The issue is not getting it to work, the issue is that project-id shouldn't be required. This code is very likely for the purpose of unit testing, and 1. I may change the project id with
firebase use, and 2. I may not want to commit my project-id into source control for open source projects, which is why.firebasercis a separate file fromfirebase.json.