Skip to content
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

Update: support globalThis (refs #12670) #12774

Merged
merged 18 commits into from Mar 17, 2020
Merged

Update: support globalThis (refs #12670) #12774

merged 18 commits into from Mar 17, 2020

Conversation

yeonjuan
Copy link
Member

@yeonjuan yeonjuan commented Jan 11, 2020

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

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

This PR is for supporting globalThis in eslint.

What changes did you make? (Give an overview)
Is there anything you'd like reviewers to focus on?

To Note
This PR upgrade eslint-utils to 2.0.0 (d3847f2) and add globalThis in environments es2020(c0357bc).

  1. By upgrade eslint-utils, some rules seem to supports globalThis. So I just added test cases for globalThis.

    • require-unicode-regexp
    • prefer-regex-literals
    • prefer-object-spread
    • prefer-named-capture-group
    • prefer-exponentiation-operator
    • no-misleading-character-class
    • no-redeclare
  2. Even upgrade eslint-utils, some rules need to be changed for recognizing globalThis. So did it.

    • no-alert
    • no-eval
    • no-obj-calls
  3. no-implied-eval was not designed to consider global reference so I changed it in another PR( Update: consider env in no-implied-eval (fixes #12733) #12757).

@eslint-deprecated eslint-deprecated bot added the triage An ESLint team member will look at this issue soon label Jan 11, 2020
@yeonjuan yeonjuan changed the title Breaking: support globalThis (ref #12670) Breaking: support globalThis (refs #12670) Jan 11, 2020
@mdjermanovic mdjermanovic added accepted There is consensus among the team that this change meets the criteria for inclusion breaking This change is backwards-incompatible rule Relates to ESLint's core rules core Relates to ESLint's core APIs and features upgrade This change is related to a dependency upgrade and removed triage An ESLint team member will look at this issue soon labels Jan 11, 2020
@@ -54,7 +67,7 @@ module.exports = {
}

for (const { node } of tracker.iterateGlobalReferences(traceMap)) {
context.report({ node, messageId: "unexpectedCall", data: { name: node.callee.name } });
context.report({ node, messageId: "unexpectedCall", data: { name: getReportNodeName(node) } });
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for fixing this bug!

Current behavior (demo):

/* eslint no-obj-calls: "error"*/
/* eslint-env browser*/

window.JSON(); // 'undefined' is not a function (no-obj-calls)

Copy link
Member

Choose a reason for hiding this comment

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

A question, maybe we could use path from iterateglobalreferences?

I guess it depends on whether we want to report "JSON is not a function" or "foo is not a function" in cases such as the following:

/* eslint no-obj-calls: "error"*/

var foo = bar ? baz : JSON;

foo();

Copy link
Member Author

@yeonjuan yeonjuan Jan 11, 2020

Choose a reason for hiding this comment

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

Ok, I'll try it! :) But what would be a better report?
In my personal opinion, current behavior looks better. But I respect what eslint members think

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure, let's wait for more opinions.

Current behavior reports "foo is not a function".

I'd vote for "JSON is not a function" as it might be a bit more helpful for the user to find out what's actually happening and why is the location of "foo()" reported as a global object call.

Copy link
Member Author

@yeonjuan yeonjuan Jan 11, 2020

Choose a reason for hiding this comment

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

I'm not sure, let's wait for more opinions.

Ok. And just to note.
The reason for my preference was that foo is not a function looks like a more intuitive explanation for the code.

I'd vote for "JSON is not a function" as it might be a bit more helpful for the user to find out what's actually happening and why is the location of "foo()" reported as a global object call.

But I agree that JSON is not a function is more helpful to find out what's actually happening. it seems more reasonable 👍

Copy link
Member

Choose a reason for hiding this comment

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

Could we do both? "foo is a reference to JSON, which is not a function"? That seems like it gives the right amount of information without being too confusing or requiring you to figure out what the code is doing.

Copy link
Member

Choose a reason for hiding this comment

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

Could we do both? "foo is a reference to JSON, which is not a function"?

That would be ideal!

I'd be also fine with "foo is not a function" in this PR (it's already much better than "undefined is not a function") and improving the message further in another PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

Could we do both? "foo is a reference to JSON, which is not a function"?

Agree! it would make the message more clear. maybe it needs new messageId like -unexpectedRefCall. I will do it. thanks :)

@mysticatea mysticatea added this to Implemented, pending review in v7.0.0 Jan 14, 2020
# Conflicts:
#	tests/lib/rules/prefer-object-spread.js
# Conflicts:
#	tests/lib/rules/no-eval.js
@ljharb
Copy link
Sponsor Contributor

ljharb commented Feb 27, 2020

fwiw i don’t see how this is breaking; if it would have broken anybody, then the name “globalThis” wouldn’t have been web compatible to add to the language. Because it was added, nobody could possibly be broken by this change who wasn’t already broken by every JS engine.

@mdjermanovic
Copy link
Member

This PR is blocked by #12757?

In particular, waiting for #12757 to be merged in order to add something to no-implied-eval?

Copy link
Member

@btmills btmills left a comment

Choose a reason for hiding this comment

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

LGTM. Thank you for updating all these rules! I particularly like the reporting improvements 👍

Copy link
Member

@nzakas nzakas left a comment

Choose a reason for hiding this comment

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

Awesome, thanks!

@@ -35,7 +48,8 @@ module.exports = {
schema: [],

messages: {
unexpectedCall: "'{{name}}' is not a function."
unexpectedCall: "'{{name}}' is not a function.",
unexpectedRefCall: "'{{name}}' is reference to '{{ref}}', which is not a function."
Copy link
Member

Choose a reason for hiding this comment

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

👍

Copy link
Member

@kaicataldo kaicataldo left a comment

Choose a reason for hiding this comment

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

Thank you for working on this!

@kaicataldo kaicataldo changed the title Breaking: support globalThis (refs #12670) Update: support globalThis (refs #12670) Mar 17, 2020
@kaicataldo kaicataldo added enhancement This change enhances an existing feature of ESLint and removed breaking This change is backwards-incompatible labels Mar 17, 2020
@kaicataldo kaicataldo merged commit 183e300 into eslint:master Mar 17, 2020
v7.0.0 automation moved this from Implemented, pending review to Done Mar 17, 2020
anikethsaha pushed a commit to anikethsaha/eslint that referenced this pull request Mar 23, 2020
* support globalThis in no-alert (ref eslint#12670)

* support globalThis in no-eval (ref eslint#12670)

* bump eslint-utils to ^2.0.0 (ref eslint#12670)

* add globalThis test cases in require-unicode-regexp (ref eslint#12670)

* add globalThis test cases in prefer-regex-literals (ref eslint#12670)

* add globalThis test cases in prefer-object-spread (ref eslint#12670)

* add globalThis test cases in prefer-named-capture-group (ref eslint#12670)

* add globalThis test cases in prefer-exponentiation-operator (ref eslint#12670)

* add globalThis test cases in no-misleading-character-class (ref eslint#12670)

* edit test cases in no-eval

* support globalThis in no-obj-calls (ref eslint#12670)

* add globalThis test cases in no-redeclare (eslint#12670)

* change to use getPropertyName

* fix tpo

* add messageID - unexpectedRefCall
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Sep 15, 2020
@eslint-deprecated eslint-deprecated bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Sep 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
accepted There is consensus among the team that this change meets the criteria for inclusion archived due to age This issue has been archived; please open a new issue for any further discussion core Relates to ESLint's core APIs and features enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules upgrade This change is related to a dependency upgrade
Projects
No open projects
v7.0.0
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

6 participants