This rule raises an issue when anonymous functions, arrow functions, or classes are used as default exports.

Why is this an issue?

When you export anonymous functions or classes as default exports, it becomes difficult to search for and identify these components throughout your codebase.

Default exports are imported with whatever name the importing module chooses. However, when the exported item itself is anonymous, there’s no consistent identifier to search for. This makes code navigation, refactoring, and debugging more challenging.

For example, if you export an anonymous class, different files might import it with different names like Component, MyComponent, or Widget. Without a consistent name at the export site, finding all usages or understanding the component’s purpose becomes much harder.

Named exports create a clear contract between modules. They establish a canonical name that can be used consistently across the codebase, improving code searchability and making the developer experience smoother.

What is the potential impact?

This issue impacts code maintainability and developer productivity. It makes codebase navigation more difficult, slows down refactoring efforts, and can lead to inconsistent naming across different parts of the application. While it doesn’t affect runtime behavior, it significantly impacts the development experience.

How to fix?

Add a name directly to the function or class being exported. This creates a clear identifier that can be consistently referenced.

Non-compliant code example

export default function () {
  return 'Hello World';
} // Noncompliant

Compliant code example

export default function greet() {
  return 'Hello World';
}

Documentation