Fix optional property types

[alecmev]

Addresses #1890 (comment)

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Install any of react-spectrum packages that bring in @internationalized/date and @react-types/shared, and type-check the project with exactOptionalPropertyTypes: true.

hourCycle causes this:

│ node_modules/@internationalized/date/dist/types.d.ts:615:11 - error TS2430: Interface 'import(".../node_modules/@internationalized/date/dist/types").ResolvedDateTimeFormatOptions' incorrectly extends interface 'Intl.ResolvedDateTimeFormatOptions'.
│   Types of property 'hourCycle' are incompatible.
│     Type '"h11" | "h12" | "h23" | "h24" | undefined' is not assignable to type '"h11" | "h12" | "h23" | "h24"'.
│       Type 'undefined' is not assignable to type '"h11" | "h12" | "h23" | "h24"'.
│ 
│ 615 interface ResolvedDateTimeFormatOptions extends Intl.ResolvedDateTimeFormatOptions {
│               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


│ node_modules/@internationalized/date/dist/types.d.ts:633:5 - error TS2416: Property 'resolvedOptions' in type 'DateFormatter' is not assignable to the same property in base type 'DateTimeFormat'.
│   Type '() => import(".../node_modules/@internationalized/date/dist/types").ResolvedDateTimeFormatOptions' is not assignable to type '() => Intl.ResolvedDateTimeFormatOptions'.
│     Type 'import(".../node_modules/@internationalized/date/dist/types").ResolvedDateTimeFormatOptions' is not assignable to type 'Intl.ResolvedDateTimeFormatOptions' with 'exactOptionalPropertyTypes: true'. Consider adding 'undefined' to the types of the target's properties.
│ 
│ 633     resolvedOptions(): ResolvedDateTimeFormatOptions;
│         ~~~~~~~~~~~~~~~

DOMProps causes this:

│ node_modules/react-aria-components/dist/types.d.ts:1148:18 - error TS2430: Interface 'GroupProps' incorrectly extends interface 'DOMProps'.
│   Types of property 'id' are incompatible.
│     Type 'string | undefined' is not assignable to type 'string'.
│       Type 'undefined' is not assignable to type 'string'.
│ 
│ 1148 export interface GroupProps extends AriaLabelingProps, Omit<HTMLAttributes<HTMLElement>, 'children' | 'className' | 'style' | 'role' | 'slot'>, _DOMProps1, HoverProps, RenderProps<GroupRenderProps>, SlotProps {
│                       ~~~~~~~~~~

[snowystinger]

this looks correct, but is really going to need to exist in so many more places
https://github.com/microsoft/TypeScript/blob/a86b5e2b01075db5046521958a3e0b905b4ca667/tests/lib/react18/react18.d.ts#L1863

Any way we can use the type from the original set instead of creating our own? maybe extends Pick<HTMLElement, 'id'>?

[alecmev]

The focus of this PR is to just fix the public API. I don't see anything wrong with adding | undefined in more places, but that's #1890.

Updated to use extends 😉

[snowystinger]

Sure, I guess i'm worried about potential regressions, and I'm also not sure that this is really all there is to fix in the public API, seems like too small a change?

[alecmev]

You're right, there's most likely more, I only submitted the changes necessary to unblock our particular cocktail of Spectrum 😛 I'll create more PRs in the future as I run into other issues.

Hopefully #1890 will be addressed soon, but until then, one option could be to add a quick smoke test, that just lists every single package as a dependency and runs tsc with skipLibCheck: false, strict: true and exactOptionalPropertyTypes: true? This will allow you to make sure that the public API is clean, without switching the whole monorepo to exactOptionalPropertyTypes: true.