Cannot find module "@firebase/auth-types"

[bnfrnz]

Describe your environment

• Operating System version: 10.13.4
• Firebase SDK version: 4.13.1
• Firebase Product: auth
• Node version: 8.11.1
• npm version: 5.6.0

Describe the problem

I can't seem to use the auth package via individual imports, for example:
import { AuthCredential, FacebookAuthProvider } from '@firebase/auth-types';

My linter doesn't complain and I see the relevant typescript definition file. But then I always get Runtime Error Cannot find module "@firebase/auth-types" even though the package and the types are installed.

Everything works perfectly fine without errors when I go via namespace, for example:
import * as firebase from 'firebase/app';
import 'firebase/auth';
const c: firebase.auth.AuthCredential = firebase.auth.FacebookAuthProvider.credential(t);
But these long types are a bit annoying. And I wonder whether tree-shaking in prod builds works this way.

I also use other packages, like database and storage, and they all work fine with individual imports, for example:
import { DataSnapshot } from '@firebase/database-types';

No problems there. Only the auth package doesn't work for me. I was wondering whether something in my npm env is mixed up but I can't see anything.

I noticed that the dist folder of all the other packages (database, storage, etc,) have .cjs.js, .esm.js, .node.cjs.js, .node.d.ts files while the auth package only has one .js file. Not sure whether that's relevant.

One quick other related feedback, in case you're interested:
Typescript can be so helpful when the definitions are accurate. It can extremely speed up learning a new API. It'd be perfect if not all functions would return Promise<any>.

For many of them the correct return type is actually Promise<void>. And for some of them the return type is actually well defined in the online reference, for example function signInWithPopup:

The (online reference) accurately says:
signInWithPopup(provider) returns firebase.Promise containing non-null firebase.auth.UserCredential

But the type definitions just say:
signInWithPopup(provider: AuthProvider): Promise<any>;

And there are dozens of other examples. If the definitions where just as accurate as the online reference, half of the times one wouldn't even need to open the browser to look up stuff.

[swftvsn]

Did you get this fixed? I have the same issue currently with firestore:

ERROR in ./src/app/service/some/some.service.ts
Module not found: Error: Can't resolve '@firebase/firestore-types' in '/Users/someuser/git/someproject/src/app/service/some'

The symptoms are the same, no other error messages and visual studio code does not see a problem, it's only when I try to run it using ng serve.

[psigen]

I am having this error as well with firestore, compiling with an app using react-scripts-ts:

../common/src/api/firebase.ts
Module not found: Can't resolve '@firebase/firestore-types' in '[...]common/src/api'

Like the above cases, linting and VSCode do not flag any issues (VSCode is in fact autocompleting the firestore-types package name for me), but yarn start reports the above error. This started when I tried to upgrade from firebase==4.8.0 to firebase==5.0.2 which requires the new typing imports.

@firebase/app-types seems to resolve just fine in the same project.

[swftvsn]

@psigen Same upgrade path for me, same visual studio / linting behavior etc. I also tested with 5.0.1, but same problems there.

Any help from Firebasers out there would be greatly appreciated - how can I diagnose this further?

[RaphaelJenni]

+1

[karsonbraaten]

+1

[raDiesle]

+1

[arashbi]

+1

[jpidelatorre]

Does anyone have news on this? A fix, probably?

I tried 377972682 but had no luck. I also tried changing versions around (including firebase 4.8.0, 4.8.1 and 4.8.2, currently using 5.0.3 and @firebase/* from latest to other versions that made chronological sense).

[wti806]

Hi, guys. Can any of you provide us a sample to reproduce this issue? We cannot reproduce it on our end. And for the typescript definition, we'll update those soon. Thanks

[pyoner]

@wti806 check my repo https://github.com/pyoner/vue-firebase-plugin
run: npm run test
here travis job result https://travis-ci.org/pyoner/vue-firebase-plugin/jobs/382075803

[jshcrowthe]

Hey all, I'm going to answer this question a little more in depth, but I'll give you a short answer first and you can read on if you'd like to know why!

tl;dr: Don't use the @firebase/* packages directly, only use the officially documented/supported firebase package (and the associated types)

I have to say thank you for the patience on this. The issue here is more a misunderstanding of what the @firebase/*-types packages are intended for vs. how they are actually being used. We've been intentionally not talking much about these packages, but it seems calling out explicitly the intended use case was required (we updated our README files for these packages in the release notes on the 5.0.4 release, for this purpose).

The error that you are seeing is due to the subtle fact that the @firebase/*-types packages contain nothing but Typescript interfaces. They don't contain an implementation of those interfaces so trying to leverage the type in something like an instanceof check or otherwise will fail (e.g. https://github.com/pyoner/vue-firebase-plugin/blob/master/src/components/Firestore.ts#L89 in the repo provided above).

When you use a package for only annotations, the package reference is compiled out by typescript and no longer remains in the codebase, which is what is intended for the *-types packages. However when you attempt to use the things that can be imported from these packages as if they were the actual classes/functions/variables, you get the error you are all seeing:

i.e.

Module not found: Can't resolve '@firebase/<PACKAGE>-types' in '[...]path/to/file'

What happens is the node resolver attempts to find the javascript file associated with the package, and load the class/function/variable imported. When it can't resolve the package to a JS file, TS throws that error.

Instead, if you were to use the officially supported API here, there would be no issue. Take the repo from above as an example:

NOT SUPPORTED (and incorrect)

import { DocumentReference } from '@firebase/firestore-types';
...

if (ref instanceof DocumentReference) {
...
}

SUPPORTED (and works great!)

import firebase from 'firebase/app';
import 'firebase/firestore';
...

if (ref instanceof firebase.firestore.DocumentReference) {
...
}

I have applied this type of fix to all of the incorrect instances in the repo and after correcting them all, the tests do pass.

Let me know if there are any questions. Know that we are working on a better module story here that will let you have a better syntax for this, but nothing to share as of yet. Stay tuned though!

[jpidelatorre]

I've been using this instead:

import { auth, firestore } from 'firebase/app'

...
  confirmation: auth.ConfirmationResult
...
  doc (path: string): firestore.DocumentReference {
...

Should I expect to have problems with that approach in the future?

[swftvsn]

Awesome detailed explanation what's happening here. Thanks for the hard work @jshcrowthe ! Let's hope the modularization effort offers nicer story soon

I actually did not read documentation at all, I blame visual studio code that so nicely proposed those imports as the first option :D