-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Fix as many linter errors as possible #4008
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -211,6 +211,9 @@ namespace ts { | |
| let assignableRelation: Map<RelationComparisonResult> = {}; | ||
| let identityRelation: Map<RelationComparisonResult> = {}; | ||
|
|
||
| // This is for caching the result of getSymbolDisplayBuilder. Do not access directly. | ||
| let _displayBuilder: SymbolDisplayBuilder; | ||
|
|
||
| type TypeSystemEntity = Symbol | Type | Signature; | ||
|
|
||
| const enum TypeSystemPropertyName { | ||
|
|
@@ -965,7 +968,7 @@ namespace ts { | |
| if (!moduleName) return; | ||
| let isRelative = isExternalModuleNameRelative(moduleName); | ||
| if (!isRelative) { | ||
| let symbol = getSymbol(globals, '"' + moduleName + '"', SymbolFlags.ValueModule); | ||
| let symbol = getSymbol(globals, "\"" + moduleName + "\"", SymbolFlags.ValueModule); | ||
| if (symbol) { | ||
| return symbol; | ||
| } | ||
|
|
@@ -1490,8 +1493,6 @@ namespace ts { | |
| return undefined; | ||
| } | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This was reported by a linter error? I think the original location was more appropriate.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It was. It was unreachable code - if this was ever compiled to a
So you can say the linter found a bug waiting to happen here.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah I see; nice!. Perhaps it would be better to just make it a
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we do that it'll have to be wrapped: /* tslint:disable:no-var-keyword */
// This is for caching the result of getSymbolDisplayBuilder. Do not access directly.
var _displayBuilder: SymbolDisplayBuilder;
/* tslint:enable:no-var-keyword */Is it worth it?
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No one is going to want that amount of verbosity to disable things, especially one liners
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I thought that was the point? You're not supposed to disable the linter.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah there is an interesting push and pull in this sort of thing. You can make the syntax to disable things as gross as possible to disincentivize disabling, on the other hand you might accept that disabling things is a fact of life and it shouldn't look like an atrocity. This is a good example of what I was mentioning to @DanielRosenwasser as far as how I only fixed the easy 80-90% cases as the rest that require non-trivial rewrites will generate some amount of discussion on whether we feel some particular situation warrants an exception. My opinion is just make the change to satisfy the linter. While I see the argument for the 'define as close to usage as possible' it's not hard to use GoToDef occasionally vs adding gross comments. |
||
|
|
||
| // This is for caching the result of getSymbolDisplayBuilder. Do not access directly. | ||
| let _displayBuilder: SymbolDisplayBuilder; | ||
| function getSymbolDisplayBuilder(): SymbolDisplayBuilder { | ||
|
|
||
| function getNameOfSymbol(symbol: Symbol): string { | ||
|
|
@@ -3448,7 +3449,7 @@ namespace ts { | |
| // type, a property is considered known if it is known in any constituent type. | ||
| function isKnownProperty(type: Type, name: string): boolean { | ||
| if (type.flags & TypeFlags.ObjectType && type !== globalObjectType) { | ||
| var resolved = resolveStructuredTypeMembers(type); | ||
| const resolved = resolveStructuredTypeMembers(type); | ||
| return !!(resolved.properties.length === 0 || | ||
| resolved.stringIndexType || | ||
| resolved.numberIndexType || | ||
|
|
@@ -7337,7 +7338,7 @@ namespace ts { | |
| } | ||
|
|
||
| // Wasn't found | ||
| error(node, Diagnostics.Property_0_does_not_exist_on_type_1, (<Identifier>node.tagName).text, 'JSX.' + JsxNames.IntrinsicElements); | ||
| error(node, Diagnostics.Property_0_does_not_exist_on_type_1, (<Identifier>node.tagName).text, "JSX." + JsxNames.IntrinsicElements); | ||
| return unknownSymbol; | ||
| } | ||
| else { | ||
|
|
@@ -7377,7 +7378,7 @@ namespace ts { | |
| function getJsxElementInstanceType(node: JsxOpeningLikeElement) { | ||
| // There is no such thing as an instance type for a non-class element. This | ||
| // line shouldn't be hit. | ||
| Debug.assert(!!(getNodeLinks(node).jsxFlags & JsxFlags.ClassElement), 'Should not call getJsxElementInstanceType on non-class Element'); | ||
| Debug.assert(!!(getNodeLinks(node).jsxFlags & JsxFlags.ClassElement), "Should not call getJsxElementInstanceType on non-class Element"); | ||
|
|
||
| let classSymbol = getJsxElementTagSymbol(node); | ||
| if (classSymbol === unknownSymbol) { | ||
|
|
@@ -7557,7 +7558,7 @@ namespace ts { | |
| // be marked as 'used' so we don't incorrectly elide its import. And if there | ||
| // is no 'React' symbol in scope, we should issue an error. | ||
| if (compilerOptions.jsx === JsxEmit.React) { | ||
| let reactSym = resolveName(node.tagName, 'React', SymbolFlags.Value, Diagnostics.Cannot_find_name_0, 'React'); | ||
| let reactSym = resolveName(node.tagName, "React", SymbolFlags.Value, Diagnostics.Cannot_find_name_0, "React"); | ||
| if (reactSym) { | ||
| getSymbolLinks(reactSym).referenced = true; | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems like the kind of place you want to mix quotes instead of using escapes (except for the hilarious inversion of ' and " on each side of the ||)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a number of places where that's true... but quote consistency is there for quote consistency, not for convenience, I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I saw a bunch more and didn't bother commenting again. I don't feel super strongly here but I always found mixing ' and " handy for cases like this but I can live without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've actually been wondering this for awhile - since template strings are a thing in JS now, why don't linters have an option to prefer those? I think they're a bit more flexible and generally easier to keep consistent with. Plus, it reduces what you have as far as string literals go from quotes and backticks to just backticks. (Since you're likely using backticks for interpolation anyway!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weswigham TSLint supports string templates for the quote rule -- it does this by simply ignoring the contents of template strings. So a "double" quote rule really means only allow double quotes or string templates.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I mean, why not forbid all quotes (single and double)? Template string literals can function as string literals handily, and it further unifies what string literals get used. Not really relevant here, I was just wondering why no linting tools seemed to support this option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@weswigham that's a valid suggestion. filed that feature request here: palantir/tslint#539
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd still prefer to be able to mix quotes. I think it would be preferable for TSLint to support "double quotes unless the string contains a double quote."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't be a problem if you used
backticks for all the quotes. Until you needed to includebackticks. 😄But no really - try not to mix quotes. It makes sense not to mix quotes if you consider searching for strings in the source code. Knowing the exact quotes used lets you (plaintext) search with much higher precision - knowing you can always Ctrl-Shift-F "Joe's "Error" Message" (over 'Joe's "Error" Message') is way easier than not knowing if it's in one of many possible string formats. Generally speaking it's worth the effort of needing to toss in a
\in your string literals every so often.