Skip to content

Enables exactOptionalPropertyTypes #431

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

dimitropoulos
Copy link
Contributor

To quote from the TypeScript team lead:

If we were to start TypeScript over again, we believe the behavior of strictOptionalProperties would be on by default
microsoft/TypeScript#44421

This configuration brings a pretty critical element to the type-soundness (critical because it drastically changes the behavior of operations that check for keys). SameValueZero checks remain unchanged, anyway, so there's basically no downside to having this rule enabled. The implementation from Anders provides some more context, as well.

Thankfully, this codebase was already pretty close to the mark, with only a few little minor things to update to increase strictness. Once this PR merges, I'd like to do to same with the connect-es repo.

@dimitropoulos
Copy link
Contributor Author

(also: note: #422 was found by enabling this setting)

@dimitropoulos dimitropoulos changed the title enables exactOptionalPropertyTypes Enables exactOptionalPropertyTypes Mar 16, 2023
@timostamm
Copy link
Member

If we were to start TypeScript over again, we believe the behavior of strictOptionalProperties would be on by default

I'd love that, but they didn't start over, and the rest of the type system doesn't work nicely with the option, requiring expressions like ...(idempotency !== undefined ? { idempotency } : {}).

I don't think anybody really likes such an expression, and we had a feature request to accept | undefined in the message initializer to avoid them (#374).

We should definitely support strictOptionalProperties once it becomes the default. Before that happens, we're better off avoiding the over-engineering.

@dimitropoulos
Copy link
Contributor Author

dimitropoulos commented Mar 20, 2023

@timostamm that's very easy, all we need to do is change the type to reflect that a literal undefined is acceptable and your concern is addressed. e90f7f1 :)

If you would like the same to be done for any others, please just say so. The fact is that codebases that have this strictness option on need to do this already today. Ones that don't, won't need to anyway. So, if nothing else, this is a QoL improvement with no downsides.

@CLAassistant
Copy link

CLAassistant commented Apr 29, 2023

CLA assistant check
All committers have signed the CLA.

@smaye81 smaye81 closed this Jun 13, 2023
@timostamm timostamm deleted the dimitri/exactOptionalPropertyTypes branch February 20, 2024 17:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants