New rule: no-default-export

[adidahiya]

In my experience, default exports are not a great practice, especially anonymous ones. I think you should always name the things you are exporting. Also, default exports allow for subtle mistakes after refactoring. With default exports, you could change the semantics of a component but it might be imported elsewhere with a name suggesting its old semantic meaning.

// app.ts
import ActionPopover from "./action";

// action.ts
export default class ActionMenu {
    ...
}
// oops, we just renamed this from popover -> menu but our consumer had no idea!

[patsissons]

If nobody is interesting in taking this one, I would love to get this in the code base today.

[adidahiya]

go for it @patsissons!

[adidahiya]

relevant to those on this thread: #2117

[Jamesernator]

I'm not really convinced by the arguments here.

Typically when using export default you have the name of the file being the same (within project conventions) as the thing being exported e.g.:

import fizzBuzz from "./fizzBuzz"
// or depending on convention in the project
import fizzBuzz from "./fizz-buzz"

Following that convention you'll never hit a case where the semantic meaning of a name is different from the import-ed name as you have to refer to exactly the file that contains that certain object, if the export changes then so must the filename.

[adidahiya]

if the export changes then so must the filename

but we don't have a lint rule to enforce that :)

[theKashey]

This is not a issue for a typeless ES6, it should not be a issue for TS.
If you are replacing ActionPopover by ActionMenu, then, well, problem is in you ;)

[anurbol]

Sorry for necro-posting. I found this rule to be very useful to enforce one style of exporting things (especially classes) across an app.