type has no index signature

[testerez]

TypeScript Version: 2.2.2

Code

function getName(id: number) {
  return {
    1: 'one',
    2: 'two',
  }[id] || 'something else';
}

Expected behavior:
{1: 'one'}[id] type should be string | undefined
So I would expect the return type to be inferred as string.

Actual behavior:

Element implicitly has an 'any' type because type '{ 1: string; 2: string; }' has no index signature.

[RyanCavanaugh]

Interesting point -- a fresh object literal type certainly could have an index signature derived from its properties. Not sure how common this pattern is in practice, though (do you really want to allocate a new object every time this function gets called?).

[testerez]

The function is to illustrate my point. I found this pattern more elegant than a switch/case for example. Is it as performant? I don't know but I don't think I care most of the time.
Are you suggesting that it could work only if [id] is applied directly to the object declaration? Ideally, I'd like to also be able to do:

const nameMap = {
  1: 'one',
  2: 'two',
};
function getName(id: number) { // inferred return type should be string
  return nameMap[id] || 'something else';
}

[RyanCavanaugh]

The implicit any there is by design -- we don't allow arbitrary indexing into objects that don't include an index signature in their type. Once an object has been "indirected" we no longer trust that it isn't an alias to some other object that might have non-string properties (in this case).

[testerez]

Ok, makes sense. Supporting my first example would already be nice for me.

[PyroVortex]

I'd go so far as to expect the return type from the first example to be 'one' | 'two' | 'something else'. At least, the only reason I would use that particular pattern would be if that were my desired return type. Otherwise the easy solution is to do:

const nameMap: { [key: number]: string } = {
    1: 'one',
    2: 'two'
};
function getName(id: number) { // inferred return type is string
    return nameMap[id] || 'something else';
}

[RyanCavanaugh]

@PyroVortex we have no way to know that the line nameMap[3] = "bob"; isn't somewhere in your program

[PyroVortex]

@RyanCavanaugh
I was specifically concerned with the pattern

return {
    1: 'one',
    2: 'two'
}[id];

for which the object is for all intents and purposes completely immutable by virtue of scoping. With this particular construction I would want the compiler to be as specific as possible in the typing. Otherwise I would fall back to the pattern of specifying a type for the constant.

[vladimir-tikhonov]

👍 for this feature. Lack of the index signature often makes auto-inherited types useless, so I need to copy-paste type inherited by typescript compiler and add index signature to it.

The fix is really simple and clear in my opinion - for objects like this:

const randomMapping = {
    stringProp: "1",
    numberProp: 2
};

Instead of the following type:

interface RandomMappingWithoutIndexSignature {
    stringProp: string;
    numberProp: number;
}

Generate type with the index signature:

interface RandomMappingWithIndexSignature {
    stringProp: string;
    numberProp: number;

    [propName: string]: string | number | undefined;
}

Am I missing something?

[lukewlms]

We have a use case where this would be nice as well. The simple Knex.js setup code below won't work without declaring the type of configs; I just want to index in and get whatever config obj matches the env.

const env = process.env.NODE_ENV || 'development';
const configs = { development, test, production };
const knex = knexConstructor(configs[env]);

However in the case @vladimir-tikhonov shows, I think that index signature can't be reasonably inferred. Even if it's const, an object can still have properties added later returning any arbitrary type. Indexing into the object would then have to return any - and that's an implicit any.

So it seems to me the design @RyanCavanaugh is referring to is correct and inevitable - there's no way to guarantee you're going to get specific types (i.e. not any) from the index signature.

[agalazis]

Also allow union types for keys please but I do believe that some sort of inference could be done here

[JakobJingleheimer]

I'm not sure if this is the same issue, but I'm getting a similar Error:

TS7017: Element implicitly has an 'any' type because type 'iAbilityModifiers' has no index signature.

Here's a simplified example:

enum eFoobar {
    foo = 'foo',
    bar = 'bar',
}

type tFooBar = { // this is `iAbilityModifiers` from the error
    [fb in keyof eFoobar]: number;
};

const character = {
    // …
    foobars: _.reduce(eFoobar,
        (acc, key) => _.merge(acc, {[key]: 10}),
        {} as tFooBar
    ),
    // …
},

{_.map(someOptions, ({ text: foobar, value: key }) => (
    <input value={character.foobars[key]} /> {/* error references this line */}
)}

According to the Mapped Types documentation, adding keyof in [fb in keyof eFoobar] is supposed to take care of the typing:

In these examples, the properties list is keyof T and the resulting type is some variant of T[P]. This is a good template for any general use of mapped types. That’s because this kind of transformation is homomorphic, which means that the mapping applies only to properties of T and no others.

[ericdrobinson]

Not sure if this is helpful in terms of adding a use-case, but I encountered what appears to be the same (or related?) issue by using a type annotation that uses an enum to restrict the names of properties. This is accomplished by defining the index signature (I think? I'm honestly not sure about the terminology here - "index signature" seems to be something very specific to TypeScript...?):

type EnumIndexedType =
{
    // Note: entries are optional.
    [TKey in SomeList]?: string;    // <-- is this not an index signature?
}

See the full example at the TypeScript playground here (issue on line 27).

If someone can point out a better or otherwise "more correct" way of doing what I'm attempting here that works as TypeScript expects, I'd very much appreciate it!

Regardless, the error as it stands is very confusing: "No Index Signature?! Isn't that, like, the only type annotation I wrote?"

[JakobJingleheimer]

@ericdrobinson, yes, the error message is extremely confusing. However, what it is actually complaining about is not the string.

What you wrote is called a Mapped Type (horrible name for trying to google it).

You've got 2 choices:

type Hashmap<K, V> = {
    [k in K]: V;
}

I usually use this with K being an enum and V being some kind of class/interface:

enum eCharacterClass {
    mage = 'mage',
    rogue = 'rogue',
    warrior = 'warrior',
}

class CharacterClass {
    health: number = 1;
    // …
}

type tCharacterClassSet = HashMap<eCharacterClass, CharacterClass>;
/*
{
    [eCharacterClass.mage]: CharacterClass{},
    [eCharacterClass.rogue]: CharacterClass{},
    [eCharacterClass.warrior]: CharacterClass{},
}
*/

So you could do:

type EnumIndexedType = Hashmap<SomeList, string>;

---

Alternatively, you could create a weak relationship:

interface WeakHashmap<V> {
    [key: string]: V[keyof V];
}

type tCharacterClassWeakSet = WeakHashmap<CharacterClass>;
/*
{
    mage: CharacterClass{},
    rogue: CharacterClass{},
    warrior: CharacterClass{},
}
*/

In this second one, the "index signature" will be string, which means there is a weak link between your Mapped Type and your enum: You can bypass the enum by supplying any value that happens to be in it ('foo' instead of SomeList.foo).