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

lib.es2022: hasOwn appears to be defined on Object prototype rather than on constructor #48206

Closed
lediur opened this issue Mar 10, 2022 · 9 comments Β· Fixed by #48207
Closed

lib.es2022: hasOwn appears to be defined on Object prototype rather than on constructor #48206

lediur opened this issue Mar 10, 2022 · 9 comments Β· Fixed by #48207
Labels
Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript

Comments

@lediur
Copy link

lediur commented Mar 10, 2022

Bug Report

πŸ”Ž Search Terms

hasOwn, Object.hasOwn, es2022, prototype, lib.es2022.object.d.ts

πŸ•— Version & Regression Information

  • This changed between versions 4.2.4 and 4.6.2

Appears to be introduced by #46291

⏯ Playground Link

Doesn't appear to reproduce on Playground or Bug Workbench, reproduces in VS Code 1.66.0-insider (e80a0ca648fe9bef07070e4f7fb04e67f2243252) running TypeScript 4.6.2.

πŸ’» Code

interface SomeComponentProps {
  requiredProp: boolean
  hasOwn?: boolean;
}

const SomeComponent: React.FC<SomeComponentProps> = () => {}

return <SomeComponent requiredProp />

πŸ™ Actual behavior

I ran into this issue because I was trying to upgrade the project from 4.3.5 to 4.6.2. The project has some object types with hasOwn as a boolean property.

// TS2322: Type '{ requiredProp: boolean }' is not assignable to type 'SomeComponentProps'.
  Types of property 'hasOwn' are incompatible.
    Type '(o: object, v: PropertyKey) => boolean' is not assignable to type 'boolean'.

πŸ™‚ Expected behavior

hasOwn should be a method of the Object constructor (Object.hasOwn), not the prototype (foo.hasOwn).

@RyanCavanaugh
Copy link
Member

This is an intended UX trade-off in JS files. Since often you'll have untyped variables, we show method help based on name-matching; this way if you're looking for help for a common method name, it shows up even without matching type information.

For more precise behavior, you can turn on checkJs.

See also #33565

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Mar 10, 2022
@lediur
Copy link
Author

lediur commented Mar 10, 2022

Thanks for the reply! I'm seeing this in a TypeScript file in a TypeScript React project when trying to upgrade from 4.3.5 to 4.6.2. Does the same behavior apply?

Let me get a more specific example of the issue I'm running into, one sec.

@RyanCavanaugh RyanCavanaugh removed the Working as Intended The behavior described is the intended behavior; this is not a bug label Mar 10, 2022
@lediur
Copy link
Author

lediur commented Mar 10, 2022

I ran into this issue because I was trying to upgrade the project from 4.3.5 to 4.6.2. The project has some object types with hasOwn as a boolean property.

e.g.

interface SomeComponentProps {
  requiredProp: boolean
  hasOwn?: boolean;
}

Using those types started failing to typecheck after the upgrade since TypeScript. For example:

const SomeComponent: React.FC<SomeComponentProps> = () => {}

return <SomeComponent requiredProp />
// TS2322: Type '{ requiredProp: boolean }' is not assignable to type 'SomeComponentProps'.
  Types of property 'hasOwn' are incompatible.
    Type '(o: object, v: PropertyKey) => boolean' is not assignable to type 'boolean'.

@RyanCavanaugh
Copy link
Member

No, you're totally right, this is just the lib being wrong. Misread what you were getting at.

@lediur
Copy link
Author

lediur commented Mar 10, 2022

No problem! I should've provided the more specific error case up front.

@lediur
Copy link
Author

lediur commented Mar 10, 2022

I'm happy to make a PR with test cases for the fix, though it might take me a bit longer since I haven't contributed to TypeScript before. If you'd like to fix this internally that's fine by me.

@RyanCavanaugh
Copy link
Member

I'll put up a PR. Thanks for the report πŸ‘

RyanCavanaugh added a commit to RyanCavanaugh/TypeScript that referenced this issue Mar 10, 2022
@RyanCavanaugh RyanCavanaugh added Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript labels Mar 10, 2022
typescript-bot pushed a commit to typescript-bot/TypeScript that referenced this issue Mar 10, 2022
Component commits:
d1b063e Move `hasOwn` from Object instance to Object constructor
Fixes microsoft#48206
DanielRosenwasser pushed a commit that referenced this issue Mar 11, 2022
Component commits:
d1b063e Move `hasOwn` from Object instance to Object constructor
Fixes #48206

Co-authored-by: Ryan Cavanaugh <ryanca@microsoft.com>
@lediur
Copy link
Author

lediur commented Mar 16, 2022

Do you know if or when this might land in a patch version?

@RyanCavanaugh
Copy link
Member

We'll be doing a patch release in the next week or two (just waiting to see if other patchworthy things appear first)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A bug in TypeScript Domain: lib.d.ts The issue relates to the different libraries shipped with TypeScript
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants