Master ESLint’s Manual Fix Rules: eqeqeq, no‑bitwise, no‑implicit‑coercion Explained

Preface

ESLint is currently the most popular and powerful JavaScript code‑validation tool. It not only helps unify code style but also helps discover potential errors. After configuring ESLint rules and integrating it into an editor or build tool, ESLint starts serving you by providing validation results and error hints during development or build time. Some ESLint rules can be auto‑fixed with a single command, while others require manual intervention to fix problematic code. This series will detail the rules that need manual fixes, helping you migrate existing code under ESLint’s protection.

eqeqeq

This rule requires replacing “loose comparisons” with “strict comparisons”. It is one of the most commonly used ESLint rules.

Everyone knows that == performs implicit type conversion (e.g., 2 == '2' evaluates to true), so developers often use == and != for “loose” comparisons.

A typical example is when we are unsure whether a backend API returns a number or a string:

if (response.errorCode == 0) {
    // do something...
}

Why forbid this? The type‑conversion rules behind == and != are far more complex than they appear. For instance, it is hard to predict the result of null == 0. This hidden complexity can cause bugs, so many code‑style guides require abandoning == and !=.

To remove these operators, simply perform an explicit type conversion before comparison:

if (parseInt(response.errorCode, 10) === 0) {
    // do something...
}

Or:

if (String(response.errorCode) === '0') {
    // do something...
}

no-bitwise

This rule disables all bitwise operators.

Bitwise operations are rarely needed in everyday development; when they appear, they are often accidental or used to look “cool”. For example, using a bitwise NOT to write an IIFE:

~function () {
    // do something...
}()

While this looks impressive, readability suffers. It is better to write an IIFE in a conventional way.

If you use a semicolon‑terminated style, write:

(function () {
    // do something...
})();

If you omit the trailing semicolon, write: <code>void function () { // do something... }(); </code> no-implicit-coercion This rule forbids implicit type conversion, including using the bitwise NOT ~ to test for -1 . An example of the “~” trick checks whether a number is -1 and is often combined with .indexOf() : <code>// check if a string contains a substring if (~str.indexOf(substr)) { // do something... } </code> This syntax is hard to read and triggers both no-implicit-coercion and no-bitwise warnings. A clearer alternative is: <code>if (str.indexOf(substr) !== -1) { // do something... } </code> Or, using ES6+ methods: <code>if (str.includes(substr)) { // do something... } </code> You can also use third‑party utilities: <code>// jQuery / Zepto if ($.inArray(member, array)) { // do something... } // Underscore / Lodash if (_.includes(array, member)) { // do something... } // Gearbox if (gearbox.str.includes(str, substr)) { // do something... } </code> As you can see, these approaches are far more readable than the mysterious tilde. (To be continued…) CSS Magic Member of Baixing.com Innovation Team, translator of “CSS Secrets”, CSS Conf speaker. This article reflects the author’s personal views and does not represent Baixing.com’s stance. (Image source: StockSnap @ Pixabay)