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

Rule Change: no-implicit-globals should not report exported #16327

Closed
kkmuffme opened this issue Sep 18, 2022 · 9 comments · Fixed by #16343
Closed

Rule Change: no-implicit-globals should not report exported #16327

kkmuffme opened this issue Sep 18, 2022 · 9 comments · Fixed by #16343
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 enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects

Comments

@kkmuffme
Copy link

kkmuffme commented Sep 18, 2022

What rule do you want to change?

no-implicit-globals

What change to do you want to make?

Implement suggestions

How do you think the change should be implemented?

A new default behavior

Example code

/* exported testFunc */

/**
 * @returns {int}
 */
function testFunc() {
    "use strict";

    return 1 + 2;
}

What does the rule currently do for this code?

When using with lexicalBindings /*eslint no-implicit-globals: ["error", {"lexicalBindings": true}]*/ it gives an error

What will the rule do after it's changed?

Not report an error, if the variable/function is "exported"

Additional comments

This was already requested previously but closed due to age #10066

Essentially it should have the same behavior as rule no-unused-vars, where exported variables/functions don't count as unused

@kkmuffme kkmuffme added enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules labels Sep 18, 2022
@eslint-github-bot eslint-github-bot bot added this to Needs Triage in Triage Sep 18, 2022
@mdjermanovic mdjermanovic moved this from Needs Triage to Feedback Needed in Triage Sep 19, 2022
@mdjermanovic
Copy link
Member

mdjermanovic commented Sep 19, 2022

Not report an error, if the variable/function is "exported"

Makes sense to me 👍

I think the main purpose of this rule is to prevent accidental creation of global variables. Declaring /* exported testFunc */ indicates the intention to create a global testFunc, and would be an alternative to the style window.testFunc = function (){} that this rule currently enforces.

@nzakas
Copy link
Member

nzakas commented Sep 21, 2022

Makes sense to me. Should this be a bug rather than an enhancement?

@nzakas nzakas moved this from Feedback Needed to Ready to Implement in Triage Sep 21, 2022
@nzakas nzakas added the accepted There is consensus among the team that this change meets the criteria for inclusion label Sep 21, 2022
@sosukesuzuki
Copy link
Contributor

Can I work on this?

@kkmuffme
Copy link
Author

Yes please :-)

@mdjermanovic
Copy link
Member

Should this be a bug rather than an enhancement?

I think this was an oversight in the design because the /* exported */ comments feature already existed when this rule was created. Currently allowed way is to add a /* global testFunc: writable */ comment (here's a playground example), which seems wrong because the variable doesn't exist before running the script.

@nzakas
Copy link
Member

nzakas commented Sep 28, 2022

Just to clarify: you’re saying this is an enhancement because the rule intentionally didn’t consider this behavior?

@kkmuffme
Copy link
Author

No, I think he means it's a bug, because it was forgotten to consider exported when this rule was created

@mdjermanovic
Copy link
Member

Sorry for the confusion. Supporting /* global testFunc: writable */ as a way to allow global function testFunc by using eslint directives may imply that the other directives such as /* exported testFunc */ were considered and intentionally not supported, but it's hard to tell because exported was not explicitly mentioned anywhere in the original issue and the PR.

Either way, I think we can treat this as a bug fix.

However, if this requires adding a new property on Variable objects (#16343 (comment)), then it seems more appropriate to mark the change as a feat, as it will include an addition to the core.

@nzakas
Copy link
Member

nzakas commented Oct 3, 2022

However, if this requires adding a new property on Variable objects (#16343 (comment)), then it seems more appropriate to mark the change as a feat, as it will include an addition to the core.

Sounds good.

Triage automation moved this from Ready to Implement to Complete Oct 14, 2022
@eslint-github-bot eslint-github-bot bot locked and limited conversation to collaborators Apr 13, 2023
@eslint-github-bot eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Apr 13, 2023
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 enhancement This change enhances an existing feature of ESLint rule Relates to ESLint's core rules
Projects
Archived in project
Triage
Complete
Development

Successfully merging a pull request may close this issue.

4 participants