Skip to content
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

Object#entries and Object#values doesn't consider optional properties as potentially undefined #52045

Closed
eliasm307 opened this issue Dec 29, 2022 · 3 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@eliasm307
Copy link

eliasm307 commented Dec 29, 2022

Bug Report

πŸ”Ž Search Terms

  • Object entries optional properties
  • Object values optional properties

πŸ•— Version & Regression Information

  • This changed between versions 4.2.3 and 4.3.5

⏯ Playground Link

πŸ’» Code

// without tsconfig.json#exactOptionalPropertyTypes enabled, optional properties can exist with `undefined`
const obj: {foo?: string, bar?: string} = {foo: undefined, bar: undefined} 

Object.entries(obj).forEach(([key, value]) => {
    const str: string = value; // value should be recognised as potentially undefined
})

Object.values(obj).forEach(value => {
    const str: string = value; // value should be recognised as potentially undefined
})

πŸ™ Actual behavior

From v4.3 it doesnt consider optional object properties as potentially undefined (with exactOptionalPropertyTypes disabled) when using Object#entries or Object#values

πŸ™‚ Expected behavior

Optional properties should mean the value when using Object#entries or Object#values is potentially undefined when exactOptionalPropertyTypes is disabled, as undefined could be assigned to the optional properties.

This allows TS to compile code with potential runtime issues from using optional properties as if they were always defined.

@MartinJohns
Copy link
Contributor

MartinJohns commented Dec 29, 2022

Duplicate of #48587. The solution to this is to enable exactOptionalPropertyTypes.

@eliasm307
Copy link
Author

Thanks @MartinJohns ! Unfortunately, enabling exactOptionalPropertyTypes in the code base im working on would require a lot of fixes so it's not an easy option and difficult to justify the work required.

I understand the concerns in the linked issue about the behaviour potentially causing issues to existing code, however I'm not clear if the change in behaviour in v4.3 was intentional or a regression?

Anyway, it would be nice if there was a way to atleast get a warning about things that might be undefined when iterating over object properties. An option could be to tie different behaviour depending on the value passed to the exactOptionalPropertyTypes option, similar to how different values change the behaviour of allowUnreachableCode. So:

  • undefined value would be the existing default behaviour
  • true would be where undefined can't be assigned to optional properties
  • false would allow assigning undefined to optional properties and also show warnings for potentially undefined property value usages

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jan 10, 2023
@RyanCavanaugh
Copy link
Member

This is the intended behavior as Martin explained.

I don't see much appetite from our side for bifurcation that flag's behavior. This is the first request I've seen where someone only wants some of its implications and it's been available for a pretty long time by now.

@RyanCavanaugh RyanCavanaugh closed this as not planned Won't fix, can't repro, duplicate, stale Jan 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

3 participants