blakeembrey
Type inference is not working
With the latest version of @types/express, I cannot use wrap() without having to explicitly declare the types of req, res and next.
Without wrap(), the types are inferred.
This is especially unfortunate because app.get() is now generic and you customize the parameter types of a route, but this way you need to duplicate them.
@felixfbecker Any ideas to fix this? We can't really give defaults in this library because this library can be used for anything - it's not specific to Express.
I'd imagine try to make the types match those in @types/express as closely as possible. It seems to have something to do with overloads.
While it is not tied to express, I'd bet that's the biggest usage and making that work shouldn't break others
@felixfbecker I'm pretty sure it would right? The types are completely generic today, I don't have any dependency on Express nor do I want to add that: https://github.com/blakeembrey/async-middleware/blob/886ce068c7e3792299b95ec93ee062dbd86a6c96/src/index.ts#L5. If I made it the Express defaults, everyone would start receiving incorrect types. E.g. I use this in my own projects for simple HTTP-based servers without Express.js.
To be clear, I was suggesting to just copy the interfaces for the handlers so they match in how they are defined (call signatures, overloads, etc) but replace anything express-specific
Do you want to submit a PR? I don't particularly want to maintain this alignment, but don't quite understand how it broke either.
In my opinion, may we simply change the defintion of interface NextFuntion
https://github.com/blakeembrey/async-middleware/blob/886ce068c7e3792299b95ec93ee062dbd86a6c96/src/index.ts#L1-L3
to
export interface NextFunction {
(err?: any): void
}
Since different package may have different definition of the NextFunction type, any may be compatible with each of the package's definition as long as it is a function with 0~1 argument.
