Closed thexeos closed 1 year ago
Also, not sure if related, but after forcing the type with const cf = (event.request as any).cf as IncomingRequestCfProperties
, trying to access cf.country
leads to
Property 'country' does not exist on type 'IncomingRequestCfProperties<unknown>'.
Property 'country' does not exist on type 'IncomingRequestCfPropertiesBase & IncomingRequestCfPropertiesBotManagementEnterprise & IncomingRequestCfPropertiesCloudflareForSaaSEnterprise<...> & IncomingRequestCfPropertiesCloudflareAccessOrApiShield'.
Note how IncomingRequestCfPropertiesGeographicInformation
is not included in the derived type definition, yet I see it included in this repo.
Is this something that you can reproduce?
Upon some further investigation, it seems like Request
from lib.dom.d.ts
always takes precedence.
Even though the custom Request
is defined in the same file, as it is not namespaced in any way, the custom definition is not used.
I have a feeling that this is the same issue as #311 (certainly the 'country does not exist' error is the same one you get with the most recent release). #310 (my pull request with the fix) might therefore be the solution.
Hey! 👋 @cloudflare/workers-types
is not compatible with lib.dom.d.ts
. Make sure you're tsconfig.json
looks something like:
{
"compilerOptions": {
...
"lib": ["ES2020"],
"types": ["@cloudflare/workers-types"]
}
}
I tried the suggestion from #85, which made
IncomingRequestCfProperties
available globally, but if I try to readevent.request.cf
, I get:I also tried
const request = event.request as Request
, but thisRequest
is not the class from this package.How can I get type hints to work?