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

no-alert and others #1105

Closed
kof opened this issue Jul 21, 2014 · 8 comments · May be fixed by iamstoick/javascript#11
Closed

no-alert and others #1105

kof opened this issue Jul 21, 2014 · 8 comments · May be fixed by iamstoick/javascript#11
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

Comments

@kof
Copy link

kof commented Jul 21, 2014

They should be smart enough to recognize that I am not calling window.alert. I have a component named alert and its declared like this var alert = require('components/notification/alert')

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@nzakas
Copy link
Member

nzakas commented Jul 21, 2014

Is there a reason you don't turn off no-alert?

@kof
Copy link
Author

kof commented Jul 21, 2014

yes I don't want somebody uses window.alert, as it is supposed by this linter ... alert in my implementation is a custom ui.

@nzakas
Copy link
Member

nzakas commented Jul 21, 2014

I'm not sure this is easily achievable. Basically we'd need to keep track of alert wherever it's used to see if it's the native one or not. I'll leave this issue open in case someone wants to investigate, but this is pretty low priority compared to our other issues.

@jonvuri
Copy link
Contributor

jonvuri commented Jul 22, 2014

Personally I think this is a valid application of the rule - that is, it should flag this case. Shadowing 'alert' means that if you copy-and-paste any of the code, or otherwise exit the shadowed scope, you suddenly have a wild alert statement in your code. It's a visible bug waiting to happen. You should just name the variable something else that doesn't shadow a dangerous global.

@kof
Copy link
Author

kof commented Jul 22, 2014

Shadowing 'alert' means that if you copy-and-paste any of the code,

no its ok to copy paste it. Your new location will do the same check and if its not declared, linter will warn. If you copy that to an application which isn't using linter -> different issue.

@michaelficarra
Copy link
Member

I agree with @kof. I think it's reasonable to expect no-alert to understand when a reference is to the global alert and when it has been shadowed. Same thing with no-console.

As for implementation, this can be easily done by either making use of escope (the reference won't have a resolved pointer to the declaration) or keeping track of shadowing ourselves similar to what we do in the block-scoped-var rule.

@nzakas nzakas added accepted There is consensus among the team that this change meets the criteria for inclusion enhancement This change enhances an existing feature of ESLint and removed triage An ESLint team member will look at this issue soon labels Jan 18, 2015
@rlidwka
Copy link

rlidwka commented Apr 7, 2015

Shadowing 'alert' means that if you copy-and-paste any of the code, or otherwise exit the shadowed scope, you suddenly have a wild alert statement in your code.

Is there a way to explicitly turn off global alert, so no-undef rule will treat it as undefined variable?

Because this is much better solution than tracking where alert variable is coming from. no-undef rule already does that.

@nzakas
Copy link
Member

nzakas commented Apr 7, 2015

You'd need to disable the browser environment to do that. There's no way to undefine a global one it's been defined.

ilyavolodin added a commit that referenced this issue May 28, 2015
Update: allow shadowed references in no-alert (fixes #1105)
@eslint-deprecated eslint-deprecated bot locked and limited conversation to collaborators Feb 7, 2018
@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 Feb 7, 2018
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
None yet
5 participants