Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow prefer-default-export to report for files without default exports #2600

Closed
imhoffd opened this issue Nov 17, 2022 · 2 comments
Closed

Comments

@imhoffd
Copy link

imhoffd commented Nov 17, 2022

I noticed that the prefer-default-export rule only triggers when there is a single named export in a file. I would like for it to trigger for any file that doesn't have a default export: whether it has multiple named exports, a single named export, or no exports at all (but each of these could be configuration options for this rule).

The following patterns would be considered warnings:

// bad1.js

// There is only a single module export and it's a named export.
export const foo = 'foo';
// bad2.js

// There is more than one named export in the module.
export const foo = 'foo';
export const bar = 'bar';

The following patterns would not be considered warnings:

// good1.js

// There is a single export and it's a default export.
const foo = 'foo';
export default foo;
// good2.js

// There is a default export.
export const foo = 'foo';
const bar = 'bar';
export default bar;
@ljharb
Copy link
Member

ljharb commented Nov 17, 2022

The default is built assuming that a file with multiple named exports is a bag of things - reducers, constants, etc. It certainly seems reasonable to add an option that would warn on any file missing a default export, though.

@imhoffd
Copy link
Author

imhoffd commented Nov 17, 2022

Thanks for that confirmation!

To elaborate on why this might be useful, in our codebase React components are default exports and their prop interfaces are named exports. It's easy enough to miss adding the default keyword to the component function, and this rule currently doesn't help with that.

In our particular case, our files are named the same as their default export (via canonical/filename-match-exported). The idea is that files are self-contained modules revolving around a single, default declaration (the main thing) which may have zero to many named declarations (supplementary things that don't really warrant a file of their own, but are useful outside the module and as such are exported).

ljharb pushed a commit to azyzz228/eslint-plugin-import that referenced this issue Nov 30, 2022
@ljharb ljharb closed this as completed in 922819f Dec 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants