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

Express getMiddleware and express-serve-static-core type not found #3222

Closed
CallMeLaNN opened this issue Aug 28, 2019 · 4 comments
Closed

Express getMiddleware and express-serve-static-core type not found #3222

CallMeLaNN opened this issue Aug 28, 2019 · 4 comments

Comments

@CallMeLaNN
Copy link

Package name: apollo-server-express
Version: v2.9.0, 5 days ago
TS version: 3.5.3

Expected behavior: No error

Actual behavior: Cannot find module 'express-serve-static-core' when I use applyMiddleware and compile using tsc.

Description:

The apollo-server-express/dist/ApolloServer.d.ts contain this function signature:

getMiddleware({...}?: GetMiddlewareOptions): import("express-serve-static-core").Router;

The generated import("express-serve-static-core") as explicit return type here is not accurate. When I dig into express core definition, I believe it should be @types/express-serve-static-core.

Any instruction to compile this package on my local?

@JacksonKearl
Copy link

These type definitions are automatically generated by the TypeScript compiler. The import("express-serve-static-core") will actually resolve to @types/express-serve-static-core when TS interprets the file, so I don't think that is the issue here. Could you have somehow not installed the required "@types/express-serve-static-core" dependency? This is implicitly required through @types/express.

abernix added a commit that referenced this issue Aug 29, 2019
The TypeScript compiler is inferring the return type of this method
accurately, but emitting `import("express-serve-static-core")` directly into
the `apollo-server-express` type definitions.

Looking at the `package-lock.json` for the Apollo Server repository, I have
a working theory that there are multple `@types/express`'s within this project
and that, when resolving the imports in the delcarations, a copy of
`express-serve-static-core` is not quite in the right resolution path —
potentially due to some package hoisting and module resolution.

To be honest, it's just a theory and I only spent about 3 or 4 minutes
looking at this, but I hope that this will address #3222 (intentionally not
using the keyword "Fixes" here because we'll wait for validation!)
abernix added a commit that referenced this issue Aug 29, 2019
The TypeScript compiler is inferring the return type of this method
accurately, but emitting `import("express-serve-static-core")` directly into
the `apollo-server-express` type definitions.

Looking at the `package-lock.json` for the Apollo Server repository, I have
a working theory that there are multple `@types/express`'s within this project
and that, when resolving the imports in the delcarations, a copy of
`express-serve-static-core` is not quite in the right resolution path —
potentially due to some package hoisting and module resolution.

To be honest, it's just a theory and I only spent about 3 or 4 minutes
looking at this, but I hope that this will address #3222 (intentionally not
using the keyword "Fixes" here because we'll wait for validation!)
abernix added a commit that referenced this issue Aug 29, 2019
The TypeScript compiler is inferring the return type of this method
accurately, but emitting `import("express-serve-static-core")` directly into
the `apollo-server-express` type definitions.

Looking at the `package-lock.json` for the Apollo Server repository, I have
a working theory that there are multple `@types/express`'s within this project
and that, when resolving the imports in the delcarations, a copy of
`express-serve-static-core` is not quite in the right resolution path —
potentially due to some package hoisting and module resolution.

To be honest, it's just a theory and I only spent about 3 or 4 minutes
looking at this, but I hope that this will address #3222 (intentionally not
using the keyword "Fixes" here because we'll wait for validation!)
@CallMeLaNN
Copy link
Author

@JacksonKearl my bad, I forgot that TS will look trough node_modules/@types/* by default, flattened for all inner dependencies.

I'm not sure if TS will always infer the return type explicitly for generated *.d.ts but I just notice it is about Yarn PnP which doesn't use node_modules.

This issue doesn't have a problem for yarn 1.17 with node_modules but only for yarn v2. I was about to report to them, probably because of @types/* resolution within packages.

@CallMeLaNN
Copy link
Author

It was fixed by #3230

@abernix
Copy link
Member

abernix commented Aug 30, 2019

@CallMeLaNN Glad that worked! 😄

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants