Aura Component Validation Rules

Rules built into Aura component code validations cover restrictions under Lightning Locker, correct use of Lightning APIs, and a number of best practices for writing Aura component code. Each rule, when triggered by your code, points to an area where your code might have an issue.

In addition to the Lightning-specific rules we’ve created, other rules are active in Lightning validations, included from ESLint basic rules. Documentation for these rules is available on the ESLint project site. If you encounter an error or warning from a rule not described here, search for it on the ESLint Rules page.

The set of rules used to validate your code varies depending on the tool you use, and the way you use it. Minimal save-time validations catch the most significant issues only, while Salesforce DX tools provide more comprehensive static code analysis.

Validation Rules Used at Save Time

The following rules are used for validations that are done when you save your Aura component code.
Validate JavaScript Intrinsic APIs (ecma-intrinsics)

This rule deals with the intrinsic APIs in JavaScript, more formally known as ECMAScript.
Validate Aura API (aura-api)

This rule verifies that use of the framework APIs is according to the published documentation. The use of undocumented or private features is disallowed.
Validate Aura Component Public API (secure-component)

This rule validates that only public, supported framework API functions and properties are used.
Validate Secure Document Public API (secure-document)

This rule validates that only supported functions and properties of the document global are accessed.
Validate Secure Window Public API (secure-window)

This rule validates that only supported functions and properties of the window global are accessed.
Disallow Use of caller and callee (no-caller)

Prevent the use of arguments.caller and arguments.callee. These are also forbidden in ECMAScript 5 and later when in strict mode, which is enabled under Lightning Locker. This is a standard rule built into ESLint.
Disallow Script URLs (no-script-url)

Prevents the use of javascript: URLs. This is a standard rule built into ESLint.
Disallow Extending Native Objects (no-extend-native)

Prevent changing the behavior of built-in JavaScript objects, such as Object or Array, by modifying their prototypes. This is a standard rule built into ESLint.
Disallow Calling Global Object Properties as Functions (no-obj-calls)

Prevents calling the Math, JSON, and Reflect global objects as though they were functions. For example, Math() is disallowed. This follows the ECMAScript 5 specification. This is a standard rule built into ESLint.
Disallow Use of __iterator__ Property (no-iterator)

Prevents using the obsolete __iterator__ property. Use standard JavaScript iterators and generators instead. This is a standard rule built into ESLint.
Disallow Use of __proto__ (no-proto)

Prevents using the obsolete __proto__ property, which was deprecated in ECMAScript 3.1. Use Object.getPrototypeOf() instead. This is a standard rule built into ESLint.
Disallow with Statements (no-with)

Prevents using with statements, which adds members of an object to the current scope in a way that makes it hard to predict or view impact or behavior. This is a standard rule built into ESLint.