Skip to content
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.

Converted open rule tests from c* to no-* #665

Closed
wants to merge 10 commits into from
Closed

Converted open rule tests from c* to no-* #665

wants to merge 10 commits into from

Conversation

JoshuaKGoldberg
Copy link

PR checklist

Overview of change:

Excluding @IllusionMH's 🏃 rules, converts list items mentioned starting from chai-* through no-* rules.

@msftclas
Copy link

msftclas commented Dec 4, 2018

CLA assistant check
All CLA requirements met.

@JoshuaKGoldberg JoshuaKGoldberg changed the title Converted open rules from a c* to no-* Converted open rule tests from a c* to no-* Dec 4, 2018
@JoshuaKGoldberg JoshuaKGoldberg changed the title Converted open rule tests from a c* to no-* Converted open rule tests from c* to no-* Dec 11, 2018
@JoshuaKGoldberg
Copy link
Author

Ugh CRLF... trying to fix up one discrepancy...

@JoshuaKGoldberg
Copy link
Author

@IllusionMH I'll leave this open in case you want to review, then merge it in if you don't get a chance or in the next week. :)

@IllusionMH IllusionMH added the PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon! label Dec 19, 2018
@IllusionMH
Copy link
Contributor

@JoshuaKGoldberg sorry for delay, I will return to reviewing this PR later today.

Copy link
Contributor

@IllusionMH IllusionMH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some duplicate blocks and folders. And looks like 1 valid case is missing in (at least I wasn't able to find it).

Will continue review tomorrow.

Copy link
Contributor

@IllusionMH IllusionMH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found few tests that are in initial files, but not in new (however, some of them are debatable and can be skipped).

At this point I think I've finished review.

@IllusionMH IllusionMH added PR: Waiting for Author Changes have been requested that the pull request author should address. and removed PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon! labels Dec 23, 2018
@JoshuaKGoldberg
Copy link
Author

Thanks for the thorough review @IllusionMH! I believe I've addressed all your points. No rush on re-reviewing 😊

@JoshuaKGoldberg JoshuaKGoldberg added PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon! and removed PR: Waiting for Author Changes have been requested that the pull request author should address. labels Dec 26, 2018
@IllusionMH IllusionMH mentioned this pull request Jan 10, 2019
4 tasks
Copy link
Contributor

@IllusionMH IllusionMH left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most fixes for first review comments are in place, however few problems are still present.

Also found some problems that I've missed during initial review 😞
Also discovered few implementation problems. Will create follow up issues for them.

const FAILURE_STRING_COMPARE_FALSE: string =
BASE_ERROR + 'Move the strict inequality comparison from the expect call into the assertion value. ';
BASE_ERROR + 'Move the strict inequality comparison from the expect call into the assertion value';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: dot was added to previous error message, but removed from this one. Nice to have them consistent.

TestHelper.assertViolations(ruleName, script, []);
});

it('should pass on correctly private static methods', (): void => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private static tests are missing from function-name/default/test.ts.lint

TestHelper.assertViolations(ruleName, script, []);
});

it('should pass on correctly protected static methods', (): void => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

protected static tests are missing from function-name/default/test.ts.lint

@@ -0,0 +1,5 @@
{
"rules": {
"function-name": [true, "validate-private-statics-as-static"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like string options like "validate-private-statics-as-static" are only checked as second option (where first one is object with RegExps).
Source and test that passes 'true' in place of object (first option) and 'validate-private-statics-as-static' as second option.

Should be

Suggested change
"function-name": [true, "validate-private-statics-as-static"]
"function-name": [true, {}, "validate-private-statics-as-static"]

And validate-private-statics-as-static/test.ts.lint is supposed to check that private static are valid when they are upper case. No errors in both test blocks.

Same problem with options position in validate-private-statics-as-private/tslint.json and validate-private-statics-as-either/tslint.json.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably related to #661

@@ -0,0 +1,5 @@
{
"rules": {
"function-name": [true, "validate-private-statics-as-private"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As described for validate-private-statics-as-static string param should be in second option position.

Suggested change
"function-name": [true, "validate-private-statics-as-private"]
"function-name": [true, {}, "validate-private-statics-as-private"]

@@ -0,0 +1,18 @@
var pattern1 = /\\x20/;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All regular expressions (except in string literals) should have single \ before x. Otherwise it is just escaped back-slash

var pattern1 = /\\x00/;
~~~~~~~ [0]
var pattern2 = new RegExp("\\x00");
var pattern3 = RegExp("\\x00");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These 2 lines should have errors too according to old tests.
On the second thought - it is an issue with implementation based on forgot escapes for \ in strings that contain strings that should have escapes for \ (and we must go deeper 😂 ) in "string-based" Mocha tests.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created #785 for further discussion

@@ -0,0 +1,5 @@
{
"rules": {
"no-suspicious-comment": [true, ["https://example.com/*"]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like RegExps shouldn't be additionally wrapped in array.
In original test all passed options are just array of strings

UPD. Looks like in this case it relies on ['123'].toString() === '123', but will fail if 2 or more strings passed


it(`should fail on lower case ${suspiciousWord} comments with colons`, (): void => {
const script: string = `
// ${suspiciousWord}: you should fix this
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like there were no actual tests for lowercase suspicious words 😂, because .toLowerCase() was missing.
It will be tested by case with link, but for consistency (with initial intent) simple case can be added too.

import { Utils } from '../utils/Utils';
import { TestHelper } from './TestHelper';

describe('noUnsupportedBrowserCodeRule', (): void => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't find new tests for this rule

@IllusionMH IllusionMH added PR: Waiting for Author Changes have been requested that the pull request author should address. and removed PR: Waiting for Reviewer A repository maintainer should take a look at the pull request soon! labels Jan 11, 2019
@JoshuaKGoldberg
Copy link
Author

Thanks for the ping - as we discussed, I'm going to close this one and open many smaller PRs for both of our sanities. For not the first time, lesson learned: giant PRs are almost never a good idea!

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
PR: Waiting for Author Changes have been requested that the pull request author should address.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants