Why are `Object.create(null)` and `{}` treated differently regarding undefined-exclusion?

[benjie]

Bug Report

🔎 Search Terms

• Object.create(null)
• POJO
• existence
• assertion
• undefined

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Object.create(null) but there doesn't seem to be any.

⏯ Playground Link

Playground link with relevant code

💻 Code

{
  const a: {b?: {c?:number}} = {};

  if (!a.b) {
    a.b = {};
  }
  a.b.c = 1; // Fine
}
{
  const a: {b?: {c?:number}} = {};

  if (!a.b) {
    a.b = Object.create(null);
  }
  a.b.c = 1; // TypeScript error: 'a.b' is possibly 'undefined'
}

🙁 Actual behavior

In the first block, everything is fine. In the second block, the a.b.c = 1 line issues the TypeScript error 'a.b' is possibly 'undefined'.

🙂 Expected behavior

Just as line 5 implies a.b exists, line 13 should do the same.

[MartinJohns]

Because Object.create(null) returns any. There's no dedicated overload for the argument null that would return {}, and it's likely not a very common use case.

[benjie]

Indeed, but why is it not treated as object rather than any?

[benjie]

it's likely not a very common use case.

When trying to avoid prototype pollution and similar issues, dealing with null-prototype objects reduces risks significantly. Any time I ever have Record<string, any> I always use Object.create(null) for it, for safety. And in performance sensitive code paths, if I know I have only used null-prototype objects then I do not need to perform Object.hasOwnProperty checks.

[MartinJohns]

Because object would not allow you to access any properties, and I guess the more common use case for this dynamic/"unsafe" object creation is to access the properties afterwards.

[benjie]

Maybe it should default to Record<any, any> or Record<number | string | symbol, any> then?

The current behavior seems suboptimal, and having to cast it when its type should already be implied via what it's being assigned to is undesirable. E.g. to change from POJO to null prototype object without affecting surrounding code we have to do quite a lot of typing:

// With POJO:
a.b = {};
// With null prototype (so verbose!):
a.b = Object.create(null) as object; // or Record<any, any>

Related issue from 2015: #3865

[MartinJohns]

I guess you could create an issue for that: Lib change issue template

In the meantime you can simply use declaration merging to create an overload for your own code base. Just create a .d.ts file with this content:

interface ObjectConstructor {
    create(n: null): {}
}

[fatcerberus]

Keep in mind that typescript will still treat the object (in the type system) as if it derives from Object - there is currently no concept of a null-prototype object type.

[NN---]

#39882

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.