src/content/docs/linter/rules/no-default-export.mdx
import { Tabs, TabItem } from '@astrojs/starlight/components';
<Tabs> <TabItem label="JavaScript (and super languages)" icon="seti:javascript"> ## Summary - Rule available since: `v1.4.0` - Diagnostic Category: [`lint/style/noDefaultExport`](/reference/diagnostics#diagnostic-category) - This rule isn't recommended, so you need to enable it. - This rule doesn't have a fix. - The default severity of this rule is [**warning**](/reference/diagnostics#warning). - Sources: - Same as [`import/no-default-export`](https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-default-export.md){
"linter": {
"rules": {
"style": {
"noDefaultExport": "error"
}
}
}
}
Disallow default exports.
Default exports cannot be easily discovered inside an editor: They cannot be suggested by the editor when the user tries to import a name.
Also, default exports don't encourage consistency over a code base: the module that imports the default export must choose a name. It is likely that different modules use different names.
Moreover, default exports encourage exporting an object that acts as a namespace. This is a legacy pattern used to mimic CommonJS modules.
For all these reasons, a team may want to disallow default exports.
Note that this rule disallows only default exports in EcmaScript Module. It ignores CommonJS default exports.
export default function f() {};
export default class C {};
export default {
f() {},
g() {},
};
export { X as default };
export function f () {};
export class C {};
export { default as X } from "mod";
module.exports = class {};