This package contains the ESLint configurations used by the Oracle JET project. These configurations come in two flavors:
- es5: this configuration is used by the JET runtime code base, which is authored in ES5.
- es6: this configuration is used by the JET tooling code base, which consists of a collection of Node-based packages that are authored in ES6.
These ESLint configurations are based on the Airbnb JavaScript Style Guide, which defines thorough JavaScript coding guidelines with the goal of ensuring a clean, consistent code base. The Oracle JET configurations introduce some deltas on top of the base ESLint configurations provided by Airbnb, as explained below.
Application developers are welcome to use the Oracle JET ESLint configurations with their own code bases, though be aware that several of the changes are fairly specific to JET (e.g. use of underscore prefixes), so please review the information below before adoption. A better option for JET-based applications that want to follow a similar coding standard without picking up the JET-specific quirks would be to use Airbnb's ESLint configurations directly.
The following sections list the modifications that the Oracle JET ESLint configurations apply on top of the base Airbnb configurations.
The items in this section apply to both of our configurations (ES5 and ES6).
ESLint rule change: no-underscore-dangle is disabled.
While the use of underscore prefixes to identify "private" properties (functions and variables) is a controversial topic, the JET code base uses this convention. We understand that naming conventions are not a robust solution for enforcing privacy. To help mitigate some of the risk, the JET runtime code base is run through the Closure Compiler, which mangles private property names.
The JET team is evaluating other approaches to private properties, and would encourage our clients to do the same.
ESLint rule change: func-names is disabled.
The Airbnb ESLint rules enforce that all function expressions must be named. This requires duplication when assigning function expressions, e.g.:
Foo.prototype.doSomething = function doSomething() { };Given that ES6 specifies new rules for function name inference, the JET code base allows anonymous function expressions.
Note that while modern browsers support function name inference, the use of anonymous function expressions can make debugging more challenging on older browsers (e.g. IE11).
ESLint rule change: no-use-before-define is disabled for functions.
Robert Martin's Clean Code promotes the notion that code should read like a top-down narrative, where higher level functions appear at the top of the module, followed by functions of increasingly lower levels of abstraction that are used to implement the preceding higher level functions. This approach to code organization is dubbed "The Stepdown Rule".
Unfortunately, the no-use-before-define ESLint rule is not compatible with this approach.
In theory, no-use-before-define intends to protect developers from relying on function hoisting behavior like this:
// Call function that has not yet been defined
doSomething();
// Define function somewhere later in the same scope
function doSomething() { }The above code relies on the fact that the definition of the doSomething function will be hoisted to the top of the scope, above the doSomething() call. This is reasonable to flag.
However, the no-use-before-define rule additionally reports the following code as a violation:
function doSomething() {
doSomeLowerLevelThing();
}
function doSomeLowerLevelThing() {}Although the above code does not rely on function hoisting, no-use-before-define still considers this code to be invalid, which prohibits the use of Martin's Stepdown Rule.
The JET team likes the Stepdown Rule enough to justify disabling the no-use-before-define rule defined by Airbnb's ESLint config. (We disable the rule just for functions, not for variables.)
If in the future we find (or implement) an ESLint rule that can distinguish between hoisting-dependent vs. hoisting-independent usages, we may start treating hoisting-dependent use-before-define cases as violations. As such, we encourage JET developers to limit reliance on function hoisting, even though this is not currently enforced.
ESLint rule change: None.
The Airbnb style guide prefers the use of function expressions instead of function declarations due to concerns over function hoisting confusion.
We have found function declarations to be readable and have increased complexity in our code base. As such, we continue to leverage this language feature.
Note that it appears that Airbnb eventually plans to enforce the use of function expressions via the func-style rule. However, this is not yet enforced, so JET does not yet make any rule changes relating to this.
ESLint rule change: linebreak-style is disabled.
Rather than enforce a consistent line break style via ESLint, we prefer to deal with this at the source control layer. This allows our developers to do development (including running ESLint) on their platform of choice without having to worry about line breaks.
ESLint rule change: no-plusplus is disabled for afterthoughts in for loops.
The Airbnb style guide raises various concerns about the use of ++ and --. While we agree with these concerns, we are comfortable with allowing these operators in for loops.
Note that, like Airbnb, we prefer higher-order functions instead of loops.
The following changes are specific to the ES6 version of the Oracle JET ESLint configuration, used by JET's Node-based tooling packages.
ESLint rule change: no-console is disabled.
For the moment, our ES6 configuration is exclusively used by JET's Node-based tooling modules. These modules use console logging to communicate with the end user.
Note we are considering generalizing our ES6 rules to apply to browser code as well, in which case we would change to (globally) disallowing console logging.
ESLint rule change: strict is disabled.
The Airbnb ESLint config forbids the use of 'use strict' as Airbnb relies on Babel to automatically insert this construct as needed. Since JET's build infrastructure does not automatically insert 'use strict', our ESLint config allows developers to do this manually.
ESLint rule change: comma-dangle is disabled.
Airbnb's (ES6) style guide mandates the use of dangling commas for the purpose of having cleaner git diffs. We find that dangling commas can be slightly less readable and slightly more confusing for developers, so we prefer to optimize for reading over diff'ing.
ESLint rule change: import/no-unresolved is disabled.
While we would like to leave this rule enabled, we are currently seeing some false positives triggered by this rule. As such, we are temporarily disabling this while we get to the bottom of the violations. We plan to re-enable this rule in a future version of our eslint-config-oraclejet.
Please consult the security guide for our responsible security vulnerability disclosure process
This project is not accepting external contributions at this time. For bugs or enhancement requests, please file a GitHub issue unless it’s security related. When filing a bug remember that the better written the bug is, the more likely it is to be fixed. If you think you’ve found a security vulnerability, do not raise a GitHub issue and follow the instructions in our security policy.
Copyright (c) 2022, 2023 Oracle and/or its affiliates Released under the Universal Permissive License v1.0 as shown at https://oss.oracle.com/licenses/upl/.