feat: fix logic for top-level this in no-invalid-this and no-eval

[mdjermanovic]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[x] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofix to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

This bug fix produces more warnings from the no-eval rule, and thus this change is marked as feat.

Tell us about your environment:

• ESLint Version: v8.11.0
• Node Version: 16.14.0
• npm Version: 8.3.1

What parser (default, @babel/eslint-parser, @typescript-eslint/parser, etc.) are you using?

default

Please show your full configuration:

Configuration

module.exports = {
    parserOptions: {
        ecmaVersion: 2015
    }
};

What did you do? Please include the actual source code causing the issue.

Online Demo

/* eslint no-invalid-this: "error", no-eval: "error" */

"use strict";

this.eval("alert('foo')");

What did you expect to happen?

No no-invalid-this errors, one no-eval error.

At the top level of scripts, this always refers to the global object, regardless of "use strict".

In browsers, the above code alerts foo, so this is valid and this.eval() is an eval call.

What actually happened? Please include the actual, raw output from ESLint.

One no-invalid-this error, no no-eval errors.

  5:1  error  Unexpected 'this'  no-invalid-this

✖ 1 problem (1 error, 0 warnings)

What changes did you make? (Give an overview)

Fixed the no-invalid-this to treat this at the top level of scripts as valid, regardless of strict mode.

Fixed the no-eval rule to treat this.eval at the top level of scripts as access to the global eval, regardless of strict mode.

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

[aladdin-add]

"use strict";

this;

I just had thought this should be undef. lol.

[aladdin-add]

💯

[btmills]

The change to no-eval LGTM, but I believe the existing behavior of no-invalid-this was already correct. In your demo link, I would expect errors from both rules. no-invalid-this "Disallows this keywords outside of classes or class-like objects." At the top level of a script, from the perspective of no-invalid-this, it's still outside of a class or class-like object, so this is still invalid even though it does have a value. The name of the rule is somewhat poor here, but the docs do a better job of conveying its purpose, which is consistent with the existing behavior.

[mdjermanovic]

I believe the no-invalid-this rule only intends to report this that is undefined and thus "invalid". Otherwise, it wouldn't check whether or not functions are in strict mode.

For example:

// not strict

function foo() {
    this.alert('foo');
}

If the intent was to "disallow this keywords outside of classes or class-like objects.", then the above this would be reported regardless of "use strict", because it is considered to be outside of classes or class-like objects. But it isn't reported, because in this case this is the global object. If we add "use strict", that this becomes undefined and it is reported by this rule.

The same applies to top-level this. The following code is not reported by no-invalid-this:

// not strict

this.alert('foo');

But the following is:

"use strict";

this.alert('foo');

That is the bug, as there's no difference between these two cases, both this refer to the global object.

[mdjermanovic]

In my opinion, we should change "Disallows this keywords outside of classes or class-like objects." to something like "Disallows use of this where it is undefined.". By the current behavior and implementation details, that was the intent for this rule. Otherwise, it wouldn't allow the following code:

/* eslint no-invalid-this: "error" */

this.alert('foo');

() => {
    this.alert('foo');
}

function foo() {
    this.alert('foo');
}

[btmills]

Based on what you've shared, the current behavior of no-invalid-this does appear to be more like "where this is not undefined" than "inside classes and class-like objects", and this change as written is consistent with the current behavior, so LGTM. Your suggested wording change to the stated purpose in the docs also LGTM. Since the behavior already seems to have drifted from the docs somewhat, I'm fine updating the docs as part of this bug fix or leaving it for a follow-up PR.

[mdjermanovic]

I'll close-reopen to try to run checks.

[mdjermanovic]

I updated the docs for no-invalid-this to clarify this rule.

I also noticed that no-eval doesn't work well with this in arrow functions, and wanted to check if that's due to changes from this PR, but it isn't. I'll fix that in another PR.