Support for ERROR & WARN per rule #1738

olore · 2016-11-17T23:36:49Z

PR checklist

Addresses an existing issue: Cleaner Configuration of Rules #629 Add severity of errors #345
New feature, bugfix, or enhancement
- Includes tests
Documentation update

What changes did you make?

Allow a "mode" for each rule in tslint.json. Anything other than "off" and the rule will run, a value of "warn" will exit with a return code of 0

  "rules": {
    "interface-name": {
      "severity": "off"
    },
    "max-line-length": {
      "severity": "error",
      "options": 140
    },
    "member-ordering": {
      "severity": "warn",
      "options": [
        "public-before-private",
        "static-before-instance",
        "variables-before-functions"
      ]
    }
}

Is there anything you'd like reviewers to focus on?

I have a few questions, please see them as comments within the diff

* For example: ``` "rules": { "align": { "mode": "off", "options": ["parameters", "arguments"] } } ``` * See it run: `npm run compile && node ./lib/tslint-cli.js src/ruleLoader.ts` * Support mode: "warn", update proseFormatter to deal with warnings

…sole.log

…ixes) * Refactor formatters to reduce duplication * Add isWarning() to test Rule classes - these seem to be compiled from somewhere? Couldn't find source ts. * Started work on getting all tests to pass

palantirtech · 2016-11-17T23:36:50Z

Thanks for your interest in palantir/tslint, @olore! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

olore · 2016-11-17T23:40:07Z

test/external/tslint-test-custom-rules/rules/ruleOneRule.js

@@ -12,6 +12,7 @@ var Rule = (function (_super) {
    Rule.prototype.apply = function (sourceFile) {
        return this.applyWithWalker(new NoFailWalker(sourceFile, this.getOptions()));
    };
+    Rule.prototype.isWarning = function() { return false; };


I couldn't figure out where these files were generated from, so I just modified by hand.

I don't think the .ts files were checked in

olore · 2016-11-17T23:40:31Z

test/formatters/stylishFormatterTests.ts

@@ -45,19 +43,11 @@ describe("Stylish Formatter", () => {

        const maxPositionTuple = `${maxPositionObj.line + 1}:${maxPositionObj.character + 1}`;

-        const expectedResult = colors.enabled ?


this test was never run with colors disabled, so I removed the ternary

olore · 2016-11-17T23:41:34Z

src/language/rule/abstractRule.ts

@@ -29,6 +30,8 @@ export abstract class AbstractRule implements IRule {

        if (Array.isArray(value) && value.length > 1) {
            ruleArguments = value.slice(1);
+        } else if (value.options) {
+            ruleArguments = arrayify(value.options);


Allow the tslint.json maintainer to no be forced to put a single value in an array

IllusionMH

Any reason to use separate array for warnings instead of extending RuleFailure interface with mode property? (or level more speaking, however differs from config field)

In any case formatters should be updated, and I think it is easier to add field check, than comparing 2 arrays if they want group errors by file.

BTW may be it make sens to use level instead of mode since it is more widely used in such context?

Extend RuleViolation to include a RuleLevel (ERROR|WARN)

olore · 2016-11-18T13:06:42Z

@IllusionMH That makes a lot of sense to me. In fact it's where I started, but because of the huge number of changes, I backed it out. What do you think about moving RuleFailure to RuleViolation? A RuleViolation will have a level that can either be WARNING or ERROR.

To me, it's a cleaner solution, I was just apprehensive about making so many changes (100+ files).

IllusionMH · 2016-11-22T00:56:51Z

I think there is no need for 100+ files change (although this level of changes probably will be required for rule test configuration files).

Probably I incorrectly used

extending RuleFailure interface with mode property

which lead to incomprehension.
I meant add mode/level property directly to this interface.

My rough estimation of changes to add level into RuleFailure .
(I'll use it instead of mode since I prefer this option and I think there were no final word on term name)

File src/language/rule/rule.ts
* Add level to IOptions
* Add level to RuleFailure constructor/toJSON
* Add getLevel method

File src/language/rule/abstractRule.ts
* Add level to this.options initialization

File src/language/walker/ruleWalker.ts
* Add private member level from options.level
* Add level to createFailure method
* Add getLevel method

File src/linter.ts
* Use filter failures array to get counts

Update formatters and utils tests (14 files) and eofline rule since they use RuleFailure constructor directly.

At this moment I'm not 100% sure if this is the best solution, since RuleWalker will store level however don't directly rely on it 😞

olore · 2016-11-22T04:00:19Z

Thanks @IllusionMH ! We were on the same page. I ended up with so many changes because I couldn't get past the name RuleFailure, so I renamed it RuleViolation. Each Violation can either be an ERROR or a WARNING (aka a RuleLevel).

Hopefully this makes sense. Appreciate the feedback and suggestions.

olore · 2016-11-23T04:18:16Z

After reading through some of the PRs and Issues, I think I underestimated how many custom rules are out there, and changing RuleFailure to RuleViolation will affect all of them :(

I will change back to RuleFailure

Update: 31 files changed instead of 115 👍

… rules

olore · 2017-02-06T20:05:26Z

@nchen63 All requested changes have been made.

Three outstanding items -

CircleCI is failing, but npm run verify works locally. I'm still digging at it, but if anyone has a suggestion, I'd appreciate it.
I could use a hand with the CHANGELOG, I added info, but it isn't exactly pretty.
Should the update to the schemastore (mentioned as non blocking) be done such that both config file formats are valid or just the new one?

nchen63 · 2017-02-07T02:39:18Z

the tests fail on my machine too. It's failing because tslint-test-custom-rules is installed intest/config/node_modules which can be found by configs in test/config while the config file for the failing test lives in test/config-legacy, which can't see the node module.

honestly, you should get rid of the config-legacy directory since it's just a copy of config but with the severity specified. It's not necessary to test every permutation of every feature with every other feature since it just adds more noise and would grow tests exponentially. Just add a few more tests to ensure that inheritance for severity is tested well.

some examples:

true -> severity: none
severity: error -> severity: warn
severity: error -> severity: error
false -> severity: none
true -> severity: warn

this might get complicated later on with inheriting default severity. For example, does a new default severity just override the old default or does it wipe out all of the custom levels? Do we need a "default" severity?

olore · 2017-02-07T12:49:02Z

Thanks for the insight. That shouldn't be a problem. I was apprehensive about killing the legacy stuff, but it definitely felt like extra baggage.

Now you feel my pain with trying to do a default severity 😄

nchen63 · 2017-02-07T15:45:08Z

I don't think you should necessarily kill the legacy stuff. You should actually leave it mostly unchanged since they test order of inheritance more than anything else.

olore · 2017-02-16T15:07:12Z

I believe I have addressed all items. Thanks for your input.

adidahiya · 2017-02-27T16:53:34Z

ping @nchen63 -- what are the remaining actions here and what is the feature rollout plan?

…fig-options # Conflicts: # CHANGELOG.md

… each failure

nchen63 · 2017-03-01T04:40:32Z

@olore nice work

we are now on our way to 5.0!

tugberkugurlu · 2017-03-10T15:17:16Z

Has this been released?

jkillian · 2017-03-10T15:30:46Z

@tugberkugurlu not in a regular release, but you can try it in this prerelease: https://github.com/palantir/tslint/releases/tag/5.0.0-dev.0

prigara · 2017-03-23T13:13:33Z

We're working on the TSLint integration in WebStorm. Can you please point me to a comment or code describing the difference between warn, warning and none. Thanks!

nchen63 · 2017-03-23T15:22:52Z

warn and warning are the same thing. none means that the rule will be ignored

palantir#1738 added support rule severity but forgot to update the example for the stylish formatter.

#1738 added support rule severity but forgot to update the example for the stylish formatter.

olore added 11 commits November 15, 2016 21:51

Support config object in tslint.json

b002f7c

* For example: ``` "rules": { "align": { "mode": "off", "options": ["parameters", "arguments"] } } ``` * See it run: `npm run compile && node ./lib/tslint-cli.js src/ruleLoader.ts` * Support mode: "warn", update proseFormatter to deal with warnings

Use arrayify to make tslint.json cleaner if only 1 option, remove con…

c597b28

…sole.log

Handle warnings in stylishFormatter, verboseFormatter & vsoFormatter

9afc794

* Formatter#format now takes failures,warnings,fixes (was failures, f…

35add24

…ixes) * Refactor formatters to reduce duplication * Add isWarning() to test Rule classes - these seem to be compiled from somewhere? Couldn't find source ts. * Started work on getting all tests to pass

Fix formatter tests

ba2b4e2

Set warnings to default to [] if none passed in

47e610e

Merge branch 'master' into enhanced-config-options

135f215

cleanup

7c5e844

Merge branch 'master' into enhanced-config-options

024570a

Merge branch 'master' into enhanced-config-options

2c74270

cleanup for public unveiling, prepping for critique

0af2c4c

olore commented Nov 17, 2016

View reviewed changes

adidahiya added PR: waiting for reviewer Status: In Discussion labels Nov 18, 2016

IllusionMH reviewed Nov 18, 2016

View reviewed changes

RuleFailure -> RuleViolation

f666d7c

Extend RuleViolation to include a RuleLevel (ERROR|WARN)

IllusionMH mentioned this pull request Nov 20, 2016

Add exceptions support for comment-format rule (fixes #562) #1757

Merged

4 tasks

WIP - broken tests

8fd7469

olore added 3 commits November 21, 2016 22:24

Merge branch 'master' into extend-rule-failure-to-include-warnings

9ab5e56

Merge branch 'master' into extend-rule-failure-to-include-warnings

4e6c572

Cleanup after comparison with master

5087498

Merge branch 'master' into enhanced-config-options

cc31e19

revert RuleViolation -> RuleFailure because it would break all custom…

2868256

… rules

olore added 2 commits February 6, 2017 12:10

Tests for setting severity with and without options

f73e930

Merge branch 'master' into enhanced-config-options

8e826ff

nchen63 mentioned this pull request Feb 10, 2017

Ability to set jsRules to all valid active rules #2198

Closed

olore added 2 commits February 11, 2017 15:34

Merge branch 'master' into enhanced-config-options

1999a4e

Update scripts for config-legacy/

1d0a6e0

JoshuaKGoldberg mentioned this pull request Feb 17, 2017

Also output json file of warnings? JoshuaKGoldberg/TSLint.MSBuild#66

Open

Noah Chen added 6 commits February 28, 2017 16:53

remove legacy tests and add boolean config inheirt test

d1016da

Merge branch 'master' of github.com:palantir/tslint into enhanced-con…

82c7036

…fig-options # Conflicts: # CHANGELOG.md

fix up constructor args

e7e99cc

use string literal union instead of enum

7d38ffb

populate rule severity in failures without specifying as argument for…

96c1f6f

… each failure

only exit(2) if errors > 0. Otherwise, exit(0) even with warnings

c15eb34

nchen63 approved these changes Mar 1, 2017

View reviewed changes

nchen63 merged commit fd54825 into palantir:master Mar 1, 2017

This was referenced Mar 1, 2017

Handle overriding just rule severity or just options #2278

Closed

Allow more granular composition of rule configuration #2284

Merged

eps1lon added a commit to eps1lon/tslint that referenced this pull request Aug 3, 2018

docs(formatters): Update stylish example

d6de32d

palantir#1738 added support rule severity but forgot to update the example for the stylish formatter.

eps1lon mentioned this pull request Aug 3, 2018

docs(formatters): Update stylish example #4095

Merged

4 tasks

giladgray pushed a commit that referenced this pull request Aug 8, 2018

docs(formatters): Update stylish example (#4095)

9b7574b

#1738 added support rule severity but forgot to update the example for the stylish formatter.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for ERROR & WARN per rule #1738

Support for ERROR & WARN per rule #1738

olore commented Nov 17, 2016 •

edited

Loading

palantirtech commented Nov 17, 2016

olore Nov 17, 2016

nchen63 Nov 18, 2016

olore Nov 17, 2016

olore Nov 17, 2016

IllusionMH left a comment

olore commented Nov 18, 2016 •

edited

Loading

IllusionMH commented Nov 22, 2016

olore commented Nov 22, 2016

olore commented Nov 23, 2016 •

edited

Loading

olore commented Feb 6, 2017

nchen63 commented Feb 7, 2017

olore commented Feb 7, 2017

nchen63 commented Feb 7, 2017

olore commented Feb 16, 2017

adidahiya commented Feb 27, 2017

nchen63 commented Mar 1, 2017

tugberkugurlu commented Mar 10, 2017

jkillian commented Mar 10, 2017

prigara commented Mar 23, 2017

nchen63 commented Mar 23, 2017

		@@ -45,19 +43,11 @@ describe("Stylish Formatter", () => {

		const maxPositionTuple = `${maxPositionObj.line + 1}:${maxPositionObj.character + 1}`;

		const expectedResult = colors.enabled ?

Support for ERROR & WARN per rule #1738

Support for ERROR & WARN per rule #1738

Conversation

olore commented Nov 17, 2016 • edited Loading

PR checklist

What changes did you make?

Is there anything you'd like reviewers to focus on?

palantirtech commented Nov 17, 2016

olore Nov 17, 2016

Choose a reason for hiding this comment

nchen63 Nov 18, 2016

Choose a reason for hiding this comment

olore Nov 17, 2016

Choose a reason for hiding this comment

olore Nov 17, 2016

Choose a reason for hiding this comment

IllusionMH left a comment

Choose a reason for hiding this comment

olore commented Nov 18, 2016 • edited Loading

IllusionMH commented Nov 22, 2016

olore commented Nov 22, 2016

olore commented Nov 23, 2016 • edited Loading

olore commented Feb 6, 2017

nchen63 commented Feb 7, 2017

olore commented Feb 7, 2017

nchen63 commented Feb 7, 2017

olore commented Feb 16, 2017

adidahiya commented Feb 27, 2017

nchen63 commented Mar 1, 2017

tugberkugurlu commented Mar 10, 2017

jkillian commented Mar 10, 2017

prigara commented Mar 23, 2017

nchen63 commented Mar 23, 2017

olore commented Nov 17, 2016 •

edited

Loading

olore commented Nov 18, 2016 •

edited

Loading

olore commented Nov 23, 2016 •

edited

Loading