no-restricted-globals
Configuration
Rule Details
Disallows specified global variable names. This is useful when a project wants to allow globals in general but forbid specific ones — for example, banning the deprecated global event in favor of an explicit handler parameter, or banning ambiguous DOM globals like name or length.
Examples of incorrect code for this rule with ["error", "event", "fdescribe"]:
Examples of correct code for this rule with ["error", "event"]:
The rule also accepts an object form so a custom message can be attached to each restricted name:
Options
The rule accepts either an array of names/objects, or a single object with the following properties:
globals— array of restricted names; each entry is either a string or{ name, message? }.checkGlobalObject— whentrue, also flags access through a global object (window.foo,self.foo,globalThis.foo, and any names configured viaglobalObjects). Defaults tofalse.globalObjects— additional global object names to check whencheckGlobalObjectis enabled.globalThis,self, andwindoware always included.
Examples of incorrect code for this rule with { "globals": ["Promise"], "checkGlobalObject": true }:
Examples of incorrect code for this rule with a custom globalObjects entry:
Differences from ESLint
- When
checkGlobalObjectis enabled, rslint always treatsglobalThis,self,window, and any configuredglobalObjectsas accessible global objects — it doesn't require them to be declared through an ESLint environment orlanguageOptions.globals. As a result, code likewindow.foo()is flagged as soon asfoois restricted andwindowisn't shadowed locally, even in projects that never configure a browser environment.