typescript definition for `context.req` is broken, defaulting to `any`
See original GitHub issueTS v4.7.2
Here’s a small example of how the typescript definition for context.req
is not correct:
const router = new Hono<Environment>();
router.get('/transfer/:token', (c) => {
const token = c.req.param('token');
return new Response(token);
})
VSCode autocomplete does not work because .req
is defaulting to any
.
https://user-images.githubusercontent.com/440299/171968643-bc5f903a-0e87-46a5-91c0-cbd2bdff06d4.mov
Issue Analytics
- State:
- Created a year ago
- Comments:6 (1 by maintainers)
Top Results From Across the Web
getStaticProps not working well with TypeScript #16522 - GitHub
Types of parameters 'context' and 'context' are incompatible. Type 'GetStaticPropsContext' is not assignable to type 'NextGetStaticPropsCtx'. Types of property ...
Read more >How define Next js Context types in Typescript? - Stack Overflow
In VS Code, you can right click on a type and click "Go to Definition". The type of GetServerSideProps is defined inside next.js...
Read more >Documentation - TypeScript 4.4
TypeScript lets us describe objects where every property has to have a certain type using index signatures. This allows us to use these...
Read more >TypeScript errors and how to fix them
A list of common TypeScript errors and how to fix them.
Read more >typescript-cheatsheet - GitHub Pages
Default Parameters. Arrow functions may also be defined with default argument values in case no respective arguments were passed, these default parameters may ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@UnsungHero97
You’re welcome. Thank you for your feedback!
It’s a very good point. That’s what I was wondering too. The answer is that I want to put everything about the request into the Request object. I think that would be easier for users to understand.
For example, the Request object has a
header
. Then, let us consider the case that we attach the method to get the header value into the Context object. What should we name the method?c.header
? But we already usec.header
to set header value likec.header('x-custom', 'value')
.c.getHeader
? Hmm… I don’t like getThing. I think it’s better to usec.req.header
.That’s the reason.
Yes it’s a good thing. Currently, we can still write following:
Awesome! I can confirm v1.4.4 is working, thanks! A quick question …
Why did you choose to extend the
Request
prototype? You already have theContext
object that I will always need to interact with anyway …… I already have to define the parameter strings to pass for
RequestParamKeyType
and I already have to define the environment type to pass forEnv
, why not attachparams
to the context object instead of extendingRequest
? This way, you do not need to modify theRequest
object (which would have avoided this issue, I think). It might also be easier to work with in typescript, something like this: