Fix Common ESLint Warnings in Existing JavaScript Code (Part 4)

ESLint is the most popular and powerful JavaScript linting tool. When code triggers an ESLint rule, the tool reports an error. This series explains rules that require manual intervention, helping you migrate existing code to ESLint protection.

no-fallthrough

Disallow using the fall‑through behavior in switch / case statements.

In JavaScript (and most C‑like languages), a common pitfall is that after a matching case executes, execution continues into subsequent cases if a break is missing. This unintuitive design is a frequent source of bugs, so ESLint provides the no-fallthrough rule to prevent accidental fall‑through.

If you intentionally rely on fall‑through, ESLint allows suppression with a specially formatted comment:

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

    case 2:
        doSomethingElse()
}

no-undef

Disallow the use of undefined variables.

The rule fires when a variable is referenced before it is declared. Often the warning involves a global variable that ESLint does not recognize.

Example:

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

// ...

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

Although window.Auth defines a global Auth, ESLint cannot infer it, so it reports an undefined‑variable warning.

Convert to a local variable

Store the global in a local constant before use:

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

Declare the global via comment

ESLint can recognize specific top‑of‑file comments that declare globals. Adding the following line tells ESLint that Auth is a global: /* global Auth */ Multiple globals can be listed, separated by commas.

Generally, the comment approach is recommended because:

No code changes are required, minimizing effort for rarely‑modified legacy code.

The intent is explicit—ESLint warnings are suppressed only for the declared global.

The comments serve as useful clues if you later aim to eliminate globals.

Conclusion

Our team adopted ESLint early as a quality guard for JavaScript. Migrating legacy code proved the toughest part, and we organized a “collective action” to eliminate old warnings. This fourth article distills the practical problems and fixes we encountered, hoping to provide reference value.

We plan to share more insights such as “How to roll out ESLint in a team” and “Choosing the right ESLint rules” in future posts.