Skip to main content

How to Resolve the "Prefer default export" ESLint Warning in JavaScript

When working with ES modules, you may encounter the ESLint warning Prefer default export (import/prefer-default-export). This rule is triggered when a module has only one export and that export is a named export.

This guide will explain why this rule exists, show you how to solve it by using a default export, and explain how and when to disable the rule if a named export is a better fit for your project's coding style.

The Core Problem: Why Does This Rule Exist?​

The import/prefer-default-export rule is a stylistic preference, not a bug-fix. Its purpose is to enforce a convention: if a module's single responsibility is to export one thing, it should be the default export for that module.

For example, this code triggers the warning because greet is the only export.

// ⛔️ Prefer default export  import/prefer-default-export
export function greet(name) {
  return `Hello, ${name}`;
}
note

The rationale is that a developer importing this module shouldn't have to guess the name of the export. A default export simplifies the import statement.

The most direct way to fix this warning is to follow its advice and change your named export to a default export.

When you have only one export, using export default makes it the "main" export of the module. This allows the importing module to assign it any name it wants.

Solution:

// ✅ No ESLint warning
export default function greet(name) {
  return `Hello, ${name}`;
}

The corresponding import statement no longer needs curly braces:

// Importing a default export
import myGreetingFunction from './greet.js';

console.log(myGreetingFunction('World'));
note

For const or other declarations, the export default must be on a separate line:

const siteName = 'My Website';

export default siteName;

Solution 2: Disabling the ESLint Rule​

Many developers and teams prefer to use named exports exclusively for consistency and to avoid the potential confusion of renamed default imports. In these cases, the best solution is to disable the rule.

Disabling for a Single Line​

If you want to override the rule for a specific case, you can use an ESLint disable comment.

For example this comment disables the rule for the very next line.

// eslint-disable-next-line import/prefer-default-export
export const GREETING = 'Hello, World!';

Disabling for an Entire File​

If a file is intended to have a single named export, you can disable the rule for the whole file.

Solution: place this comment at the top of your file:

/* eslint-disable import/prefer-default-export */

export const GREETING = 'Hello, World!';

Disabling Globally (in your ESLint config)​

If your team's style guide is to always use named exports, you can turn off this rule for your entire project in your .eslintrc.js or .eslintrc.json file.

Solution:

.eslintrc.js
module.exports = {
  // ... other rules
  rules: {
    'import/prefer-default-export': 'off',
  },
};
note

This will prevent the warning from ever appearing in your project.

Conclusion: Which Solution Should You Choose?​

The choice between a default and a named export is a matter of coding style and team convention.

  • Follow the rule and use a default export if you agree with the convention that a module with a single export should have a default one. This is the quickest way to resolve the warning for a single file.
  • Disable the rule if your project's style guide favors named exports exclusively. Many teams prefer this for consistency, as it avoids debates about when to use default and prevents developers from renaming imports, which can make a codebase harder to search.

Ultimately, the goal is consistency. Choose one approach and apply it across your project.

Table of Contents