Skip to content
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

TypeScript: @types/express version ambiguity breaks build #685

Closed
montasaurus opened this issue May 12, 2020 · 2 comments
Closed

TypeScript: @types/express version ambiguity breaks build #685

montasaurus opened this issue May 12, 2020 · 2 comments

Comments

@montasaurus
Copy link
Contributor

Related issues

#610

[REQUIRED] Version info

node: v13.12.0

firebase-functions: 3.6.1

firebase-tools: 8.2.0

firebase-admin: ^8.11.0

[REQUIRED] Test case

import * as functions from "firebase-functions";
functions.https.onCall((data, context) => {}); // error TS2707: Generic type 'Request<P>' requires between 0 and 1 type arguments.

[REQUIRED] Steps to reproduce

Upgrade the firebase-functions package to 3.6.1 with @types/express already installed and resolved to version 4.17.3 (which matches the spec for this package). Run tsc and watch the build fail.

[REQUIRED] Expected behavior

The build should succeed.

[REQUIRED] Actual behavior

The build fails because the type signatures have changed in @types/express since the spec version in package.json. Breaking change here: DefinitelyTyped/DefinitelyTyped@bb26736

- error TS2707: Generic type 'Request<P>' requires between 0 and 1 type arguments.

64         onCall: (handler: (data: any, context: https.CallableContext) => any) => import("./cloud-functions").TriggerAnnotated & ((req: express.Request<import("express-serve-static-core").ParamsDictionary, any, any, import("express-serve-static-core").Query>, resp: express.Response<any>) => void) & import("./cloud-functions").Runnable<any>;
                                                                                                                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/firebase-functions/lib/function-builder.d.ts:64:252 - error TS2694: Namespace '"/Users/adam/code/functions/node_modules/@types/express-serve-static-core/index"' has no exported member 'Query'.

64         onCall: (handler: (data: any, context: https.CallableContext) => any) => import("./cloud-functions").TriggerAnnotated & ((req: express.Request<import("express-serve-static-core").ParamsDictionary, any, any, import("express-serve-static-core").Query>, resp: express.Response<any>) => void) & import("./cloud-functions").Runnable<any>;
                                                                                                                                                                                                                                                              ~~~~~

The DefinitelyTyped bindings don't usually respect SemVer, so they should probably be pinned to a specific version in package.json or locked with package-lock.json.

Were you able to successfully deploy your functions?

No

@laurenzlong
Copy link
Contributor

This has now been fixed in 3.6.2

@LFDM
Copy link

LFDM commented Jul 8, 2020

In case someone else stumbles across this:
The fix above only partially fixes the issues with the express types. The culprit lies deeper: @types/express-serve-static-core doesn't have a fixed version within @types/express either, so it can lag behind on your system - this is what happened for me.

For now I just manually added the latest version of @types/express-serve-static-core to my own package.json (4.17.8), which works fine.
At the end of the day this needs to be fixed in @types/express.


Update: The above was a red herring. Fixed some issues, but also created others. The search continues.


Update 2:
I had to remove all older versions of @types/express-serve-static-core that were hanging out in my yarn.lock - otherwise some packages, such as firebase-functions, would refuse to use a newer version.
After I had this removed, calling yarn again (I suppose the same would apply for npm) made everyone use the newest types and I am finally able to build again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants