cloudflare / workers-types

TypeScript type definitions for authoring Cloudflare Workers.
BSD 3-Clause "New" or "Revised" License
359 stars 89 forks source link

Fix IncomingRequestCfPropertiesGeographicInformation #310

Closed philipatkinson closed 1 year ago

philipatkinson commented 1 year ago

Fix to make IncomingRequestCfPropertiesGeographicInformation work. https://github.com/cloudflare/workers-types/pull/301 actually breaks the geographic information types as it is the union of three type aliases (which only make common members available, and they have no common members).

changeset-bot[bot] commented 1 year ago

⚠️ No Changeset found

Latest commit: bc8629b8d2e1f2f45bc65a1acf1dba0bd790382d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

philipatkinson commented 1 year ago

Agree that the old types were incorrect, but your solution breaks code that would handle the situation correctly with the old types and a technically correct setup. Based on my understanding, request.cf can either be an empty object, an object with just a country "T1", or an object with a number of properties (which may or may not exist).

In that situation you are forced to code defensively in any scenario where you are, for example, trying to log the regionCode (you would have to check that cf had that specific property). As far as I can tell, that is a sequence of 'in' property checks, or optional chaining (the latter of which doesn't work for you changes).

mrbbot commented 1 year ago

Hey! I'm going to merge this and do a final release of @cloudflare/workers-types version 3. Going forward in version 4, we'll stick with the breaking, stricter types.