Tslint: no-string-literal === true shold not give a warning if type is indexable

Created on 17 May 2016 · 6Comments · Source: palantir/tslint

Bug Report

TSLint version: 3.6.0
TypeScript version: 1.8.10
Running TSLint via: Node.js

TypeScript code being linted

interface A {
    x: string;
}

const a: A = { x: "" };

a["x"] = "a"; // warning here, as expected.

interface B {
    [name: string]: string;
}

const b: B = { };

b["something-wrong"] = "a"; // no warning, as expected.
b["somethingwrong"] = "a"; // warning here, not expected!

with tslint.json:

"no-string-literal": true,

Actual behavior

[tslint] object access via string literals is disallowed

Expected behavior

no warning

Won't Fix

Source

sergey-shandar

👍15

Most helpful comment

If you index index into a value that doesn't have an indexer typedef, the compiler will raise an error.

No, it will not. At least, not version 1.8.10. This's a valid TypeScript:

interface A {
    x: string;
}
const a: A = { x: "" };
a["x"] = "a";

The purpose of the rule is to discourage any kind of string-based indexing, even if an indexer is declared. If you use this kind of pattern a lot in your code base, I don't think this rule is suitable for you.

As I showed before, it doesn't give a warning in such case

b["something-wrong"] = "a"; // no warning.

But it gives a warning in this case:

b["somethingwrong"] = "a"; // warning here, not expected!

I would propose to have two different rules:

no-string-literal

It will give warning in all of these cases

a["x"] = "a";
b["something-wrong"] = "a";
b["somethingwrong"] = "a";

But no warnings in this case

const x = "x";
b[x] = "a";

`no-default-indexer`

It will give a warning in this case

a["x"] = "a";

But no warnings in these cases

const x = "xxx";
b[x] = "a";
b["something-wrong"] = "a";
b["somethingwrong"] = "a";

sergey-shandar on 18 May 2016

👍3

All 6 comments

The kind of check you describe is currently impossible without full program type information (blocked on #680). But what would be the point of the rule then? If you index index into a value that doesn't have an indexer typedef, the compiler will raise an error.

The purpose of the rule is to discourage any kind of string-based indexing, even if an indexer is declared. If you use this kind of pattern a lot in your code base, I don't think this rule is suitable for you.

adidahiya on 18 May 2016

If you index index into a value that doesn't have an indexer typedef, the compiler will raise an error.

No, it will not. At least, not version 1.8.10. This's a valid TypeScript:

interface A {
    x: string;
}
const a: A = { x: "" };
a["x"] = "a";

The purpose of the rule is to discourage any kind of string-based indexing, even if an indexer is declared. If you use this kind of pattern a lot in your code base, I don't think this rule is suitable for you.

As I showed before, it doesn't give a warning in such case

b["something-wrong"] = "a"; // no warning.

But it gives a warning in this case:

b["somethingwrong"] = "a"; // warning here, not expected!

I would propose to have two different rules:

no-string-literal

It will give warning in all of these cases

a["x"] = "a";
b["something-wrong"] = "a";
b["somethingwrong"] = "a";

But no warnings in this case

const x = "x";
b[x] = "a";

`no-default-indexer`

It will give a warning in this case

a["x"] = "a";

But no warnings in these cases

const x = "xxx";
b[x] = "a";
b["something-wrong"] = "a";
b["somethingwrong"] = "a";

sergey-shandar on 18 May 2016

👍3

Delagen on 3 Aug 2016

Is there still anything blocking this? Judging by https://github.com/palantir/tslint/issues/680#issuecomment-231923844, it seems to me that the rules proposed earlier should have all the information they need.

lddubeau on 18 Feb 2017

TS now allows normal property-access syntax on indexable types (https://blogs.msdn.microsoft.com/typescript/2017/02/22/announcing-typescript-2-2/), so I think the rule is correct as-is regardless of types.