Generic with nested object incorrectly constraint suggestions in code completion

[Nadelopo]

🔎 Search Terms

"suggestions ", "generic", "nested object"

🕗 Version & Regression Information

• This changed between versions 4.9.5 and 5.0.4

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.0.4#code/GYVwdgxgLglg9mABMMAeAKogpgDylsAEwGdEByYOOMxAH3ICMBDAJzID4AKAfQC5EA3gCgAkPmJR+wkSLBMAtln7oA3KJEA3JgBsQSxJlz4ipClRoB+cpWqJ+ZZmzUiAvs6279hvARLXziFZmtvaOZGouAJSCLkJCKJzS4pKC6nKK9jZkADTqHnr2NAD0RYiOdMhUoi65ovn6ZMWlCNoAnpVwQlFAA

💻 Code

function fn<T extends 'foo' | 'bar'>(_: {
  test: {
    name: T
    value: T extends 'foo' ? 'foo' : 'bar'
  }
  value: T extends 'foo' ? 'foo' : 'bar'
}) {}

fn({
  test: {
    name: 'foo',
    value: '' // bar | foo
  },

  value: '' // only foo
})

🙁 Actual behavior

suggests 'bar' and 'foo' for nested object

🙂 Expected behavior

should suggest only 'bar' for nested object

Additional information about the issue

Generic type constraints do not properly narrow suggestions in nested object properties

[RyanCavanaugh]

By far the most common report we get on this situation is the opposite - that people want to see the full list of "possibly possibly-valid" strings in this position, not the set that's constrained to current other inference candidates. It's a little weird these are different but I don't think we want to move this cheese around and just make someone else unhappy.

[Nadelopo]

What's the point of seeing invalid options?

[RyanCavanaugh]

Because people will write code like this

function foo<T extends "foo" | "bar" | "baz" | "">(obj: { key: T }) { }

foo({ key: "" })

then decide they want to change key: "" to some other string, invoke completions inside the quotes, and get annoyed that they don't see the other string options.

[Nadelopo]

It seems like an empty string is actually a pretty rare edge case, and even then, pressing space would trigger suggestions anyway (or are there any other cases that could make this more complicated?).

I've implemented router typing where parameters should be inferred based on the route name, but due to the current implementation, I'm getting parameters for all routes instead, which is really inconvenient.

Also, what about the value suggestions inside and outside of test—why are they different?

[RyanCavanaugh]

It's not just the empty string case. You could have something like

function foo<T extends "foo" | "foo-bar">(obj: { key: T }) { }

foo({ key: "foo" })

where if we hard-locked to "foo" as soon as it was valid, foo-bar wouldn't be there anymore.

As I said before, it's a little weird these are different, but a change here is likely to break some other scenario in unwanted ways

[Nadelopo]

where if we hard-locked to "foo" as soon as it was valid, foo-bar wouldn't be there anymore.

This can be resolved quite easily and logically - pressing backspace makes all the correct suggestions appear. Getting all possible completions to show is trivial (a single keypress), but getting suggestions based on generic constraints is not feasible. This is disappointing.

[typescript-bot]

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