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.

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.

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