-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Update tslint.json for latest versions of tslint #3995
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
Conversation
Enforces spaces and double quotes again, and enforces no space before the colon for type definitions.
Looks great, thanks @weswigham! @danquirk can you take a quick look? |
I think the rule changes are all good but I'm inclined to say we shouldn't modify the rules without an accompanying update to the affected code. Ideally the only TSLint violations are things that TSLint doesn't support yet (ex namespaces) plus a very small number of non-standard patterns we might need to evaluate. I was hoping that the former would be taken care of soon (I need to check on TSLint's 1.5 support) to a degree where we could consider turning on the linting by default. |
The I think this line needs to be changed to var cmd = 'tslint -c tslint.json ' + f; I'll make a PR for it. |
How is it broken? Seems to be working fine on my machine:
|
etc. There's no -f in the latest tslint, it just expects the files to be passed last. |
Oh I see, they took a breaking change in their cmd line args. |
We've merged in #4005, to fix the issue in the conversation above. Now this needs to be merged to enable linting on tabs, quotes, and spaces before colons. |
👍 |
Are there code changes needed from these changes? |
The tslint isn't actually used in a build (other than #4008 fixes all the linter errors this tslint reports that aren't apparently caused by bugs in tslint (or, more accurately, by tslint not supporting TS 1.6 features yet), afaik. |
Update tslint.json for latest versions of tslint
thanks |
Enforces spaces and double quotes again, and enforces no space before the colon for type definitions.
This should fix part of #3994. I couldn't find an existing rule to cover the no multiple declaration expressions style, so that is missing from this.