Missing undefined for LinkOptions.to and other types for strict typescript exactOptionalPropertyTypes=true

Which project does this relate to?

Router/Start

Describe the bug

When strict typescript configuration with exactOptionalPropertyTypes is used, it's problematic to build components on top of Link, because its interface LinkOptions doesn't allow undefined

to?: ToPathOption<TRouter, TFrom, TTo> & {};
disabled?: boolean;
// and so on

Which should be

to?: (ToPathOption<TRouter, TFrom, TTo> & {}) | undefined;
disabled?: boolean | undefined;
// and so on

and the same for any other type where optional is used across framework types.

Example

type NavLinkButtonPropsTest = AnchorHTMLAttributes<HTMLAnchorElement> &
	LinkOptions;

export function LinkButtonTest({
	className,
	disabled,
	to,
	onClick,
	...rest
}: NavLinkButtonPropsTest): JSX.Element {
	/**
   * Type '"/" | "/welcome" | "." | ".." | undefined' is not assignable to type '"/" | "/welcome" | "." | ".."'.
     Type 'undefined' is not assignable to type '"/" | "/welcome" | "." | ".."'. (ts 2375)
   */
	return (
		<Link
			to={disabled ? "." : to}
			onClick={disabled ? (e) => e.preventDefault() : onClick}
			{...rest}
		/>
	);
}

// no problem because href is `React.AnchorHTMLAttributes<T>.href?: string | undefined`
	<a
			href={disabled ? "." : to}
			onClick={disabled ? (e) => e.preventDefault() : onClick}
			{...rest}
		/>

Expected behavior

All types across framework where ? is used should include undefined

Additional context

I'm migrating from react-router and find it a bit annoying to add non-null assertions for all components as a temporary solution and forced to set exactOptionalPropertyTypes to false.

Start by locating the LinkOptions type used by Link and inspect the other framework types with optional properties. Check how these types are consumed under exactOptionalPropertyTypes=true, then update the affected declarations so optional values accept undefined and verify the example builds without errors.