Thank you for submitting your issue. We are operating at reduced capacity from Dec 18 2020 to Jan 4 2021. Please expect delayed responses. For more urgent requests please reach us via our support channels https://firebase.google.com/support
When using node 14 with typescript's @types/[email protected], attempting to compile with tsc gives a conflicting definition of 'node' error:

I need to use node 14 because something in fs-extra is broken in node 12.
```tsconfig.json
"dependencies": {
"@types/node": "^14.14.16",
...
"firebase-admin": "^9.4.2",
```
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
for some reason if I downgrade firebase-admin to 9.0.0 it seems to work fine
for some reason if I downgrade firebase-admin to 9.0.0 it seems to work fine
That's strange. Both v9.0.0 and v9.4.0 depends on same version of @types/node.
https://github.com/firebase/firebase-admin-node/blob/v9.0.0/package.json#L58
https://github.com/firebase/firebase-admin-node/blob/v9.4.0/package.json#L61
However, v9.4.0 ships with auto-generated typings that contains /// <reference types="node" /> directives. It seems in that case tsc requires both the SDK and the user code agree on the typing versions they use.
This is partially related to #1100. I'm not sure what the right fix in this case could be. Will continue to explore options. Also appreciate any thoughts from other TS experts who might know better.
This has proven to be a problem for us also. Please consider to work on it.
+1 this issue is preventing us from upgrading as well
I was also having this issue, but I only needed to downgrade to 9.3.0 to resolve it, not all the way to 9.0.0.
+1 I have downgraded to 9.3.0 to resolve it, but it got an error when sending push notification FirebaseMessagingError: SenderId mismatch
This is a major issue preventing the usage of admin sdk 9.7.0.
It seems firebase-admin uses @google-cloud/storage which uses grpc-js which in turn uses @types/node above version 12. On the other hand firebase-admin uses @types/node version 10 which is quite outdated. Hence the conflict.
Why don't we update the @types/node for admin sdk?
I started a PR to fix this issue. I also published a temporary package "firebase-admin-nikhilag" (https://www.npmjs.com/package/firebase-admin-nikhilag) to unblock my own project.
I don't think the PR will actually "fix" this issue (see my comment on the PR). You will most likely need a project-level workaround like this in the tsconfig.json to resolve it:
"typeRoots": [
"node_modules/@types"
]
@hiranya911 Thanks for reviewing the fix. With my fix, I did try with "@types/node": "^14.14.16", and it worked correctly. I followed the same usage pattern as grpc-js where they use the greater than or equal to sign to allow higher versions: "@types/node": ">=12.12.47",
Please let me know if I am missing something.
I'm trying to repro the original issue, but so far haven't been able to. I've tried firebase-admin 9.7.0 and 9.6.0, and @types/node v12 and v14. But none of the combinations have resulted in a compilation error. Can somebody share a minimal, complete repro for us to test?
Here's one of the configurations I tested:
{
"name": "helloworld",
"version": "1.0.0",
"description": "",
"main": "index.js",
"author": "",
"license": "ISC",
"dependencies": {
"@types/node": "^14.14.16",
"firebase-admin": "9.6.0"
},
"devDependencies": {
"typescript": "^3.8.0"
}
}
import { Agent } from 'http';
import * as admin from 'firebase-admin';
export function init(agent: Agent): admin.app.App {
return admin.initializeApp({
httpAgent: agent,
});
}
export function createCustomToken(): Promise<string> {
const auth: admin.auth.Auth = admin.auth();
return auth.createCustomToken('alice');
};
export function addUser(): Promise<void> {
const db: admin.firestore.Firestore = admin.firestore();
return db.collection('users').doc().set({uid: 'alice'})
.then(() => {
console.log('DONE');
});
}
@hiranya911 I will work over the weekend to try to find a repro. In my backend code, I did check that 9.7.0 is failing but 9.8.0 is working correctly.
@hiranya911 I was unable to repro the issue using your code but in my backend code, I get these errors (and more):-


Tried a bunch of imports but nothing seemed to break in your code above. Will definitely give it a few more tries.
Going to close this for now, since #1258 provides a solution for now.
Most helpful comment
I was also having this issue, but I only needed to downgrade to
9.3.0to resolve it, not all the way to9.0.0.