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

🔍 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.

Start by comparing the shown JavaScript behavior under //@ts-check or checkJs with the equivalent .ts example. Determine how TypeScript should infer properties assigned after {} and how an optional tsconfig flag would control it. Done means TypeScript mode supports the requested object shape inference without changing emitted JavaScript.