I go back and forth on exactOptionalPropertyTypes personally, but your point about downstream code is an important one. @dfreeman @jamescdavis I would love your thoughts here as well!

I've been using exactOptionalPropertyTypes on projects and I'm liking its explicitness. Especially for cases where objects are spread (or Object.assigned), it's really nice to be able to allow a property to be overridden, but not cleared, e.g. https://tsplay.dev/wXKrDW

But regardless of my personal opinion, I agree it should be required to ensure downstream compatibility.

@dfreeman and I were discussing this this morning and he pointed out that it's actually a bit weirder than "just require it" allows for: in fact, what is "safe" for a consumer depends on what the library has chosen, because of the way exactOptionalPropertyTypes interacts with variance.¹

Consider the following two examples, with exactOptionalPropertyTypes and function arguments and return types respectively (playground):

function exampleIn(arg: { foo?: string }) {
  if ('foo' in arg) {
    arg.foo.length;
  }
}

declare function exampleOut(): { foo?: string });

In the exampleIn case, if the library has exactOptionalPropertyTypes on, then changing from { foo?: string } to { foo?: string | undefined } changes what is legal for a caller to pass, because the arg.foo.length check no longer passes: the presence or absence of foo within the object no longer specifies that it is a string. But callers do not know this unless they also have exactOptionalPropertyTypes on: with it off, they can explicitly pass { foo: undefined } in either case.

The exact inverse is true for the exampleOut case: explicitly returning { foo: undefined } will break the same in-based narrowing done by a caller who is working with the return type.

(Notably, the check is an important one: the type system is catching real runtime issues!)

The only way that this can be safe is not by requiring exactOptionalPropertyTypes in libraries but rather by requiring libraries to specify which setting they use and informing consumers that they will only be safe if they share the choice made by the libraries they consume. The obvious problem here is: if you consume two libraries with different settings for this, you're out of luck. So… maybe we need to (a) specify that libraries should always use exactOptionalPropertyTypes and (b) specify that consumers must do so as well or risk breakage. That feels not great, but… 🤷🏼‍♂️

Long-delayed follow-up: this has been integrated since either beta.3 or the (just-published) beta.4. 👍🏼