Version 4.21.0 and older now pulls in types for 5.0.0 that are incompatible. #5987
Comments
|
Express itself does not depend on or include By the way, the types for express are maintained in the DefinitelyTyped project: |
|
Not sure why but the v5 types are pushed to v4.17.21 causing a lot of linting errors for me I have to pin types back to 4.17.20 for now: |
|
I'm with the same issue. I would like to ask if will fix it? By the way for who are using npm this could be a solution:
otherwise can use the @Trinovantes solution for yarn |
|
For anyone with this issue, can you please do The v5 types were most assuredly not pushed to v4. The DT publisher knows when it's about to publish a package with the same contents and skips it. When the v5 types were published, v4 did not change and you can see in the version list only v5 getting updated:
|
|
@JimmyBjorklund what version range did you have for your Please follow jakebailey's steps and report back.
This would always have been necessary to guard against pulling a new major's types when they were published. The difference today is that there is a new major's types on DT |
|
Ah, I forgot you can use It seems there's actually a lot of broken packages: |
|
"*" means "resolve to any version", it doesn't neccesarily mean "resolve to latest". They are all compatible with v4 and v5, and if we had written |
|
I'm using yarn 1.22.22 and it's resolving to the latest version for me |
|
You may have to use overrides, then. (Yarn v1 is very old and unmaintained; maybe it's just an unfixed bug 🤷) From the DT side, it's possible that using peer deps would help (once we implement support for them), but if package managers are still preferring newer versions, it may not help. |
|
|
Those experiencing this problem need to ensure:
CC @JimmyBjorklund @Trinovantes Example of
|
they are not. |
|
Yea that was a misunderstanding on my part. Turns out I was using |
|
I just merged in support for peerDependencies on DefinitelyTyped, so theoretically packages like |
|
I am currently making a service with Nodejs and TS using Clean Arch and I have an error with my controllers and routes These are the routes and these are the controllers but this error is solved when I change the version to a previous one does anyone know what is happening or can help me with this? |
in your - if (error) return res.status(400).json({ message: error });
+ if (error) { res.status(400).json({ message: error }); return; }
# or
+ if (error) return void res.status(400).json({ message: error });returning In your case the statement
Therefore, you need either to separate sending from returning (make it two statements) or suppress returning (by using the That's how you migrate to |
|
@JimmyBjorklund , I think this conversation is drifting from the idea of the original topic that seems to be resolved, isn't it? |
|
We at least have a solution for how to fix the issue. One could say that the original issue is closed yes. |
|
@RobinTail Thank you so much for your help, I owe you one ❤️ |
express-session is the culprit for me as well after migrating from Thanks to @RobinTail 🙏, I managed to fix this and I'm writing an issue to As @RobinTail stated :
|
|
If anyone is beating their head against the wall trying to use the |
I feel like Asking devs to break this into: when they need eject is not only less clear (we send the response and then we decide to end the handler) but I would argue, less secure. I feel like the suggested idiom, while understandable from a TS perspective, is just inviting the route handler to keep churning when a developer forgets to insert I would love to see this decision reconsidered and to see the It has always been optional to return from an express request handler (we know that the request has already been sent from res.send/res.json), but it is a pattern that a lot of folks have adopted over the years that I would argue is both more readable and more secure. |
Version 4.21.0 and older now pulls in types for 5.0.0 that are incompatible.
Adding the types/express 4.17.21 fixes the issue but it was not needed until today
The text was updated successfully, but these errors were encountered: