Add object shape inference to TypeScript mode (already in JSDoc+JavaScript mode)

[matthew-dean]

🔍 Search Terms

object inference through property assignment

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

So, whilst adding in JSDoc + //@ts-check to an existing project, I came across a type-inference feature that as far as I know, only exists in type-checked JavaScript.

In JavaScript, you can write a function like this:

// somefile.js
export function makeObject() {
  const foo = {};
  foo.a = 1;
  foo.b = '2';
  return foo;
}

However, what astonished me is that this type inference does not break when you add // @ts-check to the file. foo is properly typed based on assignment, and no error is thrown.

The Feature Request - Add this existing feature to .ts files (via a tsconfig flag)

// somefile.ts
export function makeObject() {
  const foo = {};
  foo.a = 1;
  foo.b = '2';
  return foo; // has a final shape of { a: number, b: string }, the same as JS does
}

TypeScript documentation, of course, says you can never do this, that object types cannot be inferred from assignment, and must instead either be typed up-front or, when inferred, inferred only by defining all the properties in the object. However, I've found there are lots of times when you want to infer an object's shape via assignment of the initial (function) scope (which is what is already supported in TS-checked JavaScript.

📃 Motivating Example

Mostly this would improve DX. I've had a number of situations where working JavaScript code had to be re-written the "TypeScript way" in order to get type inference. In many cases, migrating from JS to TS is a matter of adding types. However, in the case of objects, most legacy code "builds up" objects through assignment.

So, say you have this simple example, similar to something I've encountered often in legacy codebases:

export function makeObject() {
  const foo = {};
  foo.a = 1;
  foo.b = '2';
  return foo;
}

Now, immediately TypeScript will error at foo.a, because it says Property 'a' does not exist on type '{}'

Okay, so next the new TypeScript developer says, "alright, I'll add types to this object".

export function makeObject() {
  const foo: { a: number, b: string } = {};
  foo.a = 1;
  foo.b = '2';
  return foo;
}

This is, of course, wrong again. TypeScript says: Type '{}' is missing the following properties from type '{ a: number; b: string; }': a, b

But the developer is going to add them! In this case, if you don't want to massively refactor, you're left with a few bad options.

export function makeObject() {
  const foo = {} as { a: number, b: string };
  foo.a = 1;
  foo.b = '2';
  return foo;
}

This satisfies the types but it teaches a new TS developer to lean on as. Some teams will disallow / strongly discourage as as part of their linting settings because of the danger it implies.

Another option is this:

export function makeObject() {
  const foo: { a?: number, b?: string } = {};
  foo.a = 1;
  foo.b = '2';
  return foo as Required<typeof foo>;
}

Once again, we're leaning on string type assertion and using as.

The Obvious Question

Okay, so a seasoned / opinionated TS developer would say, "Why not just add a & b to the object definition"? Yes, in this very simple case, that's not much refactoring, but in codebases I've worked with, simply moving all the individual property assignments to the initial object declaration is a massive amount of refactoring. But even more importantly, IMO, better questions are:

1. Should migrating to TypeScript force massive refactoring if the inference capabilities are already there?
2. Is TypeScript "JavaScript + types"? Or is it a different language with specifically-omitted JavaScript patterns? Ideally, IMO, whatever types we can infer in a .js file with JS patterns, we should be able to infer in a .ts file with TS patterns.

(Of course, maybe this feature already exists in TypeScript with some TSConfig pattern that I couldn't find?)

💻 Use Cases

1. What do you want to use this for?
   Every legacy code base I encounter.

2. What shortcomings exist with current approaches?
   Blunt-force type-assertions or massive refactoring

3. What workarounds are you using in the meantime?
   Both of the options from #2 OR simply using JSDoc + // @ts-check or "checkJs": true. I'm finding that in many cases, migrating from JS to TS is just too painful and time-consuming for some codebases because of object / constructor handling alone.

[fatcerberus]

Sort of an inverse-duplicate of #30009 (that issue asks for JS to behave like TS instead of vice versa)

[MartinJohns]

Duplicate of #47559. This is intentionally not supported: #47559 (comment)

For adding properties onto existing objects, this is an intentional opt-out for TS; the complexity of doing this in all possible cases would be too much of a performance/complexity trade-off for what it allows you to do.

This issue was fairly recent, I doubt something changed about this.

[matthew-dean]

@MartinJohns I don't see it as a duplicate because it is supported and it is supported when type checking, so this isn't asking to add this to TypeScript in terms of its type engine. There's nothing net new being added except to do the same type of type inference for another file extension which also has type annotations and type checking. It's frustrating to wholly opt-in or opt-out to invisible magical type inference behaviors which are advantageous to one file type or another.

In other words, there is type inference in .js that has better DX than .ts, but it's not opt-inable.

And contrary to this comment on that file by @Josh-Cena...

If you just want helpful hints instead of validation, then JSDoc is the right fit for you!

... they aren't hints! You actually get proper (and validated) types! The JS is type-checked and the type is actually concrete and enforced in other type-checking. I tested it by importing the .js file into a TS file and restricting the parameter sent to a function, and it threw type errors based on the JS inference.

So all I'm asking is that this is turned onto a feature flag that can be flagged on for .ts as well, because the feature is already present and working.