-
Notifications
You must be signed in to change notification settings - Fork 889
New rule to forbid access to commonly-confused ambient globals #922
Comments
Also referencing this thread because I'm unclear how such a lint rule could even be defined given the number of such variables. Perhaps the solution can be approached by using a modified function Apple() {
console.log(event); // error; event no longer defined as a global
console.log(window.event); // ok
} Thoughts? Not tested this so this might break some type definitions...? |
@myitcv Is such an approach feasible without lib.d.ts modularity in TS 2.0? This issue is fairly similar to #327. Both would almost certainly involve using the type checker (but not necessarily #680 because we could just tell langauge services to consider |
It is possible but perhaps not the cleanest solution. We use custom
My plan would be to try a version of Theoretically, if I published these modified files others would also be able to use the |
Any progress on this? ESLint has the rule no-restricted-globals which covers this, maybe a similar definition can be used here too? |
Copying discussion from #3824: What if you declare something in an Or what about a project that uses Maybe the rule should get the list of files TS is compiling with (can we do that?) along with its compiler options, and add |
IMO, there should be no difference between official
A more concret example would be helpful. Maybe This issue is related. microsoft/TypeScript#2715
We are banning globals, no matter where they are declared. |
This rule was added: https://palantir.github.io/tslint/rules/no-restricted-globals/ |
For example,
window.event
(here in lib.d.ts) is often referenced in erroneous code like this:The text was updated successfully, but these errors were encountered: