Support exactOptionalPropertyTypes #1319
Merged
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
A key being optional is different than the value being optional. Former indicates missing keys, while latter indicate, required key but missing value.
When defining a type like this, we're explicitly stating that the key must exists, but its value could be undefined.
Validconst invalid: OpenAPIConfig = {myKey: undefined}Invalidconst invalid: OpenAPIConfig = {}Which is different from following that says, key could be missing - which translates into the value being missing as well. Which is why with
exactOptionalPropertyTypesall optional keys need to explicitly stateundefinedas value type.Validconst invalid: OpenAPIConfig = {myKey: undefined}Validconst invalid: OpenAPIConfig = {}Now, you might actually want the user to be explicit with the keys, in which case can change it, but I'm inferring from context that it's not important.
In any case, in that scenario, dropping the optional keyword on the key would change that. But that might break for users who are currently not passing explicit keys. This maintains backwards compatibility.