onChange type breaks after updating to 9.1.0

[xec]

After updating from 8.10.0 to 9.1.0 typechecking breaks our build, caused by a change to the discriminating union determining the type of onChange.

To Reproduce

1. Go to Codesandbox: https://codesandbox.io/p/sandbox/datepicker-onchange-type-ddjhws
2. Look at the type inferred for the onChange function

as long as typescript is in strict mode (or "noImplicitAny" is enabled) the following code will no longer compile:

<DatePicker
  onChange={(x) => {
    // typechecking fails - x is "any" in 9.1.0 :(
    // expected x to be "Date | null"
  }}
/>

Error message:

Parameter 'x' implicitly has an 'any' type. typescript(7006)

Expected behavior

Expected the inferred type of onChange first parameter to be Date | null as it was in 8.10.0 and 9.0.0

If either selectsRange or selectsMultiple is true, the onChange type is inferred correctly as expected.

Screenshots

Additional context

Explicitly specifying the parameter type inline would silence the error for this specific instance:

<DatePicker
  onChange={(x: Date | null) => {
    // ...
  }}
/>

Unfortunately this is not an option for us since it's part of a distributed (re-styled) wrapper and we want to avoid breaking sub-dependant projects :(

Possible fix

Looks like the change was introduced here:
3a82fd1

Adding the ? to selectsMultiple?: true means it accepts undefined as well, not only when selectsMultiple is true, making typescript unable to determine which part of the union should apply since they all match when undefined.

Removing the question marks introduced on lines 260 and 272 in the commit linked above seems to resolve the issue.

---

Edit: the type appears to work fine in 9.0.0 as well

[martijnrusschen]

Thanks for the detailed report and root cause analysis @xec!

I've opened #6205 to fix this. The solution is to revert the optional discriminators back to required:

• selectsRange?: true → selectsRange: true
• selectsMultiple?: true → selectsMultiple: true

This restores proper type inference for the common case where neither prop is specified.

The original issue (#6131) was for wrapper components spreading props - those users can work around this with a type assertion:

<DatePicker {...(props as DatePickerProps)} />

[xec]

Thank you so much for the quick response and fix :)

How often do you release patches? No pressure, only reason I´m asking is our dependabot keeps trying to update to latest react-datepicker and creating broken pull requests :(

[Kurioni]

@xec, You can restrict updates to this dependency in dependabot.yml using the ignore option. For example, specify a range of versions to ignore:

ignore: 
- dependency-name: "react-datepicker" 
versions: [">8.4.x"]

Then Dependabot will only update the package to 8.4.x, and will not offer newer versions (with bugs).

[fasergeyte]

When the release this fix will be published?