Rules that should be refined further

[magurotuna]

Now that all the recommended rules have been implemented, it's good time to look back at the rules again.
I have looked through how the rules are implemented, and have noticed that some rules need more refinement. Current issues I've found are:

• unable to catch violations in nested blocks, just like no-unsafe-finally doesn't catch nested violations #327
• some cases that should be reported are ignored (e.g. normal funcions are considered, but arrow functions are not)
• insufficient test cases (I think porting the ESLint's tests would be good as it would guarantee the compatibility with ESLint.)

rules that need refinement

Note that this list has been made from my quick look, thus it may contain rules that actually don't need any fix.

recommended_rules

• for-direction fix(for-direction): handle nested for loops #333
• getter-return fix(getter-return): handle nested stuff #334
• no-array-constructor fix(no-array-constructor): handle nested stuff #335
• no-async-promise-executor fix(no-async-promise-executor): handle nested or parenthesized stuff #338
• no-case-declarations fix(no-case-declarations): handle nested switch statements #356
• no-class-assign fix(no-class-assign): increase tests and fix to pass them #352
• no-compare-neg-zero fix(no-compare-neg-zero): handle nested stuff #354
• no-cond-assign fix(no-cond-assign): handle nested stuff #389
• no-constant-condition Rules that should be refined further #330
• no-dupe-args fix(no-dupe-args): handle nested function's arguments and remove unnecesarry allocation #390
• no-dupe-keys fix(no-dupe-keys): handle nested objects & getter and setter with the same name #406
• no-duplicate-case refactor(no-dupe-keys): switch to asset_lint_err! macro #520
• no-empty fix(no-empty): handle nested empty blocks in switch #394
• no-ex-assign fix(no-ex-assign): handle nested assignments correctly #545
• no-func-assign fix(no-func-assign): handle FnExpr and nested assignments #540
• no-global-assign (Looking at it again, there seems no issue)
• no-inferrable-type fix(no-inferrable-types): handle nested things properly #543
• no-invalid-regexp
• no-new-symbol refactor(no-new-symbol): switch to asset_lint_err! macro #578
• no-obj-calls
• no-prototype-builtins
• no-self-assign refactor(no-self-assign): switch to asset_lint_err! macro #605
• no-setter-return refactor(no-setter-return): refine with ast-view and add sufficient tests #632
• no-shadow-restricted-names refactor(no-shadow-restricted-names): switch to assert_lint_err! macro #606
• no-this-alias (refactor(no-this-alias): switch to assert_lint_err! macro and cleanup #624)
• no-unsafe-finally fix(no-unsafe-finally): catch violations in nested finally blocks #328
• no-unsafe-negation refactor(no-unsafe-negation): add doc & hint, switch to macro in test, etc. #654
• no-with
• prefer-as-const (fix(prefer-as-const): handle var_decl that has no decl #568)
• use-isnan
• valid-typeof (fix(valid-typeof): allow comparison with variables other than undefined, null, Object #570)

all_rules

• default-param-last fix(defualt-param-last): handle nested violations #329
• explicit-function-return-type [WIP] Refine explicit-function-return-type #332 (WIP)
• no-const-assign
• no-eval
• no-non-null-asserted-optional-chain
• no-sparse-arrays
• no-throw-literal
• no-var
• single-var-declarator

[bartlomieju]

@magurotuna have you found bugs in all the listed rules?

IIRC most of implemented rules have ESLint tests ported, but I'm more than happy to add more tests if they are lacking.

[magurotuna]

@bartlomieju

have you found bugs in all the listed rules?

not necessarily, but I feel like lots of the listed rules are unable to catch nested violations.
For example, with no-with rule, if we run a test like

    assert_lint_err_n::<NoWith>(
      "with (foo) { with(bar) { console.log(42); }}",
      vec![0, 13],
    );

it is expected to pass, but the rule doesn't detect with(bar). Most likely this goes for the other rules.

I will fix them one by one, giving priority to "recommended" rules over the others. Hopefully it will not take much time, but I guess it will...

[bartlomieju]

@magurotuna I see, thanks for digging into this problem.

[bartlomieju]

@magurotuna is this issue still relevant?

[magurotuna]

@bartlomieju Not really sure, let me check if the issue remains.