Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tslint no-string-literal check is wrong #126

Closed
evmar opened this issue Apr 8, 2016 · 2 comments
Closed

tslint no-string-literal check is wrong #126

evmar opened this issue Apr 8, 2016 · 2 comments
Assignees

Comments

@evmar
Copy link
Contributor

evmar commented Apr 8, 2016

[16:19:04] [gulp-tslint] error (no-string-literal) main.ts[43, 18]: object access via string literals is disallowed

However, the object in question is from minimist and defined as

        export interface ParsedArgs {
            [arg: string]: any;
            _: string[];
        }

so I should be able to index into it with a string.

What's the fix -- fix tslint or fix our settings?

@mprobst
Copy link
Contributor

mprobst commented Apr 11, 2016

I think this rule does not do what I hoped it'd do. It just checks if whatever is in the brackets could in theory be a valid identifier on the object, but not whether the object allows it :-(

@alexeagle do you know if tslint does or will support type based checks?

@alexeagle
Copy link
Contributor

palantir/tslint#680

They can't run the typechecker because they only do file-by-file analysis
without typechecking. This is motivating the design of something they
haven't shown me called tsvet, as well as my thing

On Mon, Apr 11, 2016 at 3:38 PM Martin Probst notifications@github.com
wrote:

I think this rule does not do what I hoped it'd do. It just checks if
whatever is in the brackets could in theory be a valid identifier on the
object, but not whether the object allows it :-(

@alexeagle https://github.com/alexeagle do you know if tslint does or
will support type based checks?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#126 (comment)

mprobst added a commit that referenced this issue Apr 11, 2016
It turns out it only syntactically checks object accesses, and is overly aggressive in doing so. Fixes #126.
mprobst added a commit that referenced this issue Apr 11, 2016
It turns out it only syntactically checks object accesses, and is overly aggressive in doing so. Fixes #126.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants