Skip to content

Cannot use firebase.firestore and other namespaces types after upgrading to 8.0.0 #4004

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

Closed
dbanisimov opened this issue Oct 28, 2020 · 3 comments

Comments

@dbanisimov
Copy link

  • Firebase SDK version: 8.0.0
  • TypeScript version: 4.0.3
  • Operating System version: Win 10

After upgrading to 8.0 directly using firebase.firestore or any other product namespaces types doesn't work.

This doesn't work:

// mymodule.ts

let ts: firebase.firestore.Timestamp;

The typescript error: Namespace '"..../node_modules/firebase/index"' has no exported member 'firestore'.ts(2694)

This works:

let ts: firebase.default.firestore.Timestamp;

As well as this:

import type firebase from 'firebase';
let ts: firebase.firestore.Timestamp;

What is the correct way to use these namespace types in modules? Should the explicit type import be used going forward instead of relying on the global declaration?

@Feiyang1
Copy link
Member

Interesting. Are you using script tags to include firebase, and use firebase as a global variable in your module files? Just trying to understand why you only want to import types.

Yes, it's recommended to explicit import firebase for namespace types in modules. The global types become a little awkward to use now( you have to add default as you noted) since we changed the typings to match our esm export.

You probably don't need to use type-only imports, unless you use --isolateModules(more on this in Typescript release notes). You can use regular imports, Typescript will know you only use types and erase firebase from Typescript's output.

@dbanisimov
Copy link
Author

The app is bundled with webpack. It's a React app and our code is structured in a way that there is a single context provider that does import firebase from 'firebase' and then passes the initialized app instance to other component down the tree. Other components use this instance, so there is no need to import firebase again. But they may still need the types for some parts of the code to be strongly typed.

Apart from that there were a couple of places where global types were useful before:

  1. Utils functions that don't talk to firebase directly, but still need firebase types for strong typing.
  2. Our own global .d.ts file. We put the types for the documents stored in firestore in a central declarations file and it is using firebase types for Timestamps and FieldValues.

I think that both of the later can be solved by directly importing types with minimal changes. For the former, adding type imports to many components doesn't look that pretty, but I guess it's better than adding .default.

@Feiyang1
Copy link
Member

That makes sense. Thanks for the clarification! I will close the issue now.

@firebase firebase locked and limited conversation to collaborators Nov 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants