Mastering ESLint: How to Handle no-fallthrough and no-undef Rules

Preface ESLint is currently the most popular and powerful JavaScript code validation tool. When our code triggers an ESLint rule, ESLint reports an error. This series will detail the ESLint rules that require manual intervention to fix, helping you migrate existing code under ESLint protection.

no-fallthrough

Disallows using the fall‑through feature in switch / case statements.

In JavaScript (and most C‑like languages) a common pitfall is "fall‑through". After a matching case runs, if no break is encountered, execution continues into all subsequent cases.

This unintuitive design is a frequent source of bugs, so ESLint provides the no-fallthrough rule to prevent accidental fall‑through.

If you really need fall‑through, ESLint allows you to suppress the warning with a specially formatted comment:

switch (foobar) {
    case 1:
        doSomething()
        // fall through

    case 2:
        doSomethingElse()
}

no-undef

Disallows the use of undefined variables.

The rule warns when a variable is used before being declared. Often the warning occurs for global variables that ESLint does not recognize.

Example:

// namespace
window.Auth = { /* ... */ }

// ...

// init
if (page && Auth[page]) {
    Auth[page]()
}

In the if statement above, Auth is referenced. Although we defined the global variable with window.Auth = …, ESLint cannot detect it, so the rule reports an error.

There are two ways to fix this:

Convert to a Local Variable

Store the global variable in a local variable before using it:

// init
const Auth = window.Auth
if (page && Auth[page]) {
    Auth[page]()
}

Declare Global Variable via Comment

ESLint can recognize specific comments at the top of a file. Adding the following line tells ESLint that Auth is a global variable:

/* global Auth */

Multiple globals can be declared by separating them with commas.

Generally, the comment‑based approach is recommended because:

No code changes are needed, which minimizes effort for legacy code.

The intent is clear—explicitly suppressing the "undefined variable" warning.

These comments serve as useful clues if you later aim to eliminate global variables.

Conclusion

Our team adopted ESLint early as a quality safeguard for JavaScript. Over time we refined the rules and documentation, summarizing our experiences in this four‑part series to help others migrate legacy code and address common ESLint warnings.

ESLint is a valuable tool, and we hope every team can benefit from it. Future posts will cover topics like "How to Successfully Introduce ESLint in a Team" and "Choosing the Right ESLint Rules for Your Project".