This rule raises an issue when a module uses a default import from a utility library that exposes many independent functions, instead of using explicit named or method-level imports.

Why is this an issue?

Importing an entire utility library as a single default object (e.g., import _ from "lodash") creates potentially significant maintenance and performance liabilities:

• Inhibits Dead-Code Elimination (Tree-Shaking): Modern bundlers rely on static analysis to detect and remove unused code. When a monolithic utility object is imported, the bundler must assume that any or all methods could be evaluated dynamically at runtime. This forces the entire library into the final client bundle, drastically increasing bundle sizes and worsening application load times.
• Obscures Module Dependencies: Top-level named imports serve as an immediate inventory of a file’s external dependencies. Hiding utilities behind a generic _ or R namespace forces maintainers and code reviewers to scan the entire file to understand exactly which functions are being utilized.
• Encourages Monolithic Coupling: Importing a catch-all object makes it effortless to chain or append arbitrary utility calls throughout the file, rather than keeping the module’s scope focused and decoupled.

This rule currently applies to the following utility libraries: * lodash * lodash-es * rambda * validator

How to fix it

Refactor the imports to explicitly request only the required functions. For modern ES modules (like lodash-es or rambda), use named imports. For legacy CommonJS environments (like standard lodash), use direct method-level subpath imports.

Code examples

Noncompliant code example

import _ from "lodash-es"; // Noncompliant: Defeats the purpose of using the ES variant
import lodash from "lodash"; // Noncompliant: Forces the entire monolithic bundle to load
import R from "rambda"; // Noncompliant: Obscures which functional utilities are utilized
import validator from "validator"; // Noncompliant: Forces the entire monolithic bundle to load

const names = _.map(users, "name");
const ids = lodash.map(users, "id");
const doubled = R.map(value => value * 2, values);
const isValidEmail = validator.isEmail(email);

Compliant solution

import { map as mapFromLodashEs } from "lodash-es"; // Compliant: Allows bundlers to tree-shake other methods
import map from "lodash/map"; // Compliant: Only loads the specific map module
import { map as rambdaMap } from "rambda"; // Compliant: Explicitly documents the dependency
import isEmail from "validator/es/lib/isEmail"; // Compliant: Only loads the specific isEmail module

const names = mapFromLodashEs(users, "name");
const ids = map(users, "id");
const doubled = rambdaMap(value => value * 2, values);
const isValidEmail = isEmail(email);

Resources

Documentation

• MDN web docs - import
• Webpack Tree Shaking Documentation - Tree Shaking
• Lodash Documentation - Per Method Packages
• Rambda Documentation - Rambda API reference
• Validator.js Documentation - Tree Shakeable ES Imports

Related rules

• {rule:javascript:S2208} - Wildcard imports should not be used