Home > Software engineering >  Can I force anonymous default export?
Can I force anonymous default export?

Time:05-18

If you have a file named same as default export, why do you need to name this export? I am not DRY there.

We have a rule to prevent the anonymous default export, but how can I do the opposite and force an error when somebody is not using an anonymous export?

CodePudding user response:

If you have a file named same as default export, why do you need to name this export?

You don't. That's why you are linking to a linter rule - it's not required, but considered "best practice" by some, because

Ensuring that default exports are named helps improve the grepability of the codebase by encouraging the re-use of the same identifier for the module's default export at its declaration site and at its import sites.

Basically, people think that if you have

export default () => { console.log('Hello'); }

people are more likely to do

import logHello from 'sayHello'; // file one
import greeting from 'sayHello'; // file two
import sayHello from 'sayHello'; // file three

but that if you do

const sayHello = () => {
    console.log('Hello');
}
export default sayHello

people will more consistently do

import sayHello from 'sayHello';

which makes the code easier to read, because the same function is called the same thing no matter where you import it from.

When you ask

how can I force it?

I am assuming you mean how can you force the linter to accept your anonymous default export? You would either need to inline disable the rule:

/* eslint import/no-anonymous-default-export: [2, {"allowArrowFunction": true}] */
export default () => {}

or update your eslint config to accept it in general.

CodePudding user response:

If you really want to have an anonymous default export even though your linter prevents it, you can use comments to disable eslint rules. So, for your scenario, // eslint-disable-next-line import/no-anonymous-default-export should work. Or you can modify the eslint config if you want to disable that rule everywhere.

But you should read the justification for naming default exports:

Ensuring that default exports are named helps improve the grepability of the codebase by encouraging the re-use of the same identifier for the module's default export at its declaration site and at its import sites.

For exported classes in particular, another thing to consider is that naming the exported class will set its constructor.name, which can be useful.

const bar = class Foo {};
(new bar()).constructor.name; // 'Foo'
  • Related