FR: export as namespace admin; in declaration file

[ibrahimduran]

I've been trying to use admin.auth.DecodedIdToken in my global declaration file but I've found out that export = admin only exports types in admin without nested namespaces. I did a quick research and learned that export as namespace admin; can be used to whole namespace.

Is there any particular reason for not to export whole namespace?

[hiranya911]

Following compiles just fine:

import * as admin from 'firebase-admin';

const token = 'foo';
admin.auth().verifyIdToken(token)
  .then((decoded: admin.auth.DecodedIdToken) => {
    console.log(decoded);
  })

What is your use case?

[ibrahimduran]

I need to extend Express Request object to support user property on authenticated requests but currently DecodedIdToken interface is not accessible from declaration files.

my_typing.d.ts

/// <reference types="express" />
/// <reference types="firebase-admin" />

declare module Express {
  export interface Request {
    user?: admin.auth.DecodedIdToken // Error: Cannot find namespace admin.
  }
}

[hiranya911]

Following seems to work for me (at least my IDE is happy with it):

import * as admin from 'firebase-admin';

declare module Express {
  export interface Request {
    user?: admin.auth.DecodedIdToken;
  }
}

[ibrahimduran]

VSCode also does not complain about it but I think it's because using top-level import statements causes a file to be treated as a source file. So as I know it's not possible to import from module in a global declaration file, in such case it breaks the whole declaration.

Compiler throws Property 'user' does not exists on type 'Request'. error for code above.

[hiranya911]

We use imports in our typings file: https://github.com/firebase/firebase-admin-node/blob/master/src/index.d.ts#L17

[ibrahimduran]

Yes, I'm aware of that import statements are used in modules declaration files. As I said:

using top-level import statements causes a file to be treated as a source file

By source file what I really mean is module file. Module files have their own scope and have to be directly imported to use them as said in Microsoft/TypeScript#5506.

What I'm really trying to achieve here is extend the Express.Request in a global declaration file instead of a module file that needs to be imported everywhere and strictly set as type of variables.

Here's the minimal reproduction repository. Only way I managed to compile this code is using export as namespace admin;. I'm gladly open to all suggestions.

[LogansUA]

Hello.

I'm also suffering from this. I want to add type hinting for firebase message payload (i.e. MessagingPayload type, but since the index.d.ts export only admin namespace - I can't use anything from it 😞

Here's an example

import * as admin from 'firebase-admin';

export class PushService {
    /**
     * Generate payload
     *
     * @returns {admin.messaging.MessagingPayload}
     */
    public generatePayload(): admin.messaging.MessagingPayload {
        return {
            notification: {
                title: 'Title',
                text: 'Body',
            },
            data: {
                route: '/example',
            },
        };
    }
}

Error message:

TS2339: Property 'MessagingPayload' does not exist on type '(app?: App) => Messaging'.

Do you have any solutions for such cases?

Thank you.

[hiranya911]

The above code sample compiles fine. And VSCode wires the type definitions correctly. Are you sure it's the above code snippet that triggers the given error? It is rather strange since the code makes no references to App, which is indicated in the error message.

[LogansUA]

@hiranya911 I'm using WebStorm 2018.1. Regarding App, you're right, sorry but I took this code slightly out of context of my application, but the problem still the same, the admin not exporting anything useful.

Here's the screenshot from my IDE

[hiranya911]

But if the code compiles with tsc (which it does), and works fine in some IDEs (e.g. VSCode), I can't see this as a problem in the SDK:

[ibrahimduran]

I've just come across a workaround posted in 2016 for this issue, which still works as a charm. It can be found here with additional details microsoft/TypeScript#7352 (comment). It worked for me and I think this issue can be closed since there is a workaround without modifying the library code.