Rule to prohibit default exports

[dead-claudia]

TSLint has a similar rule, where it prohibits default exports. Basically this (second case generating a warning):

// good-1.js
export function foo() {}

// good-2.js
function foo() {}
export {foo}

// bad-1.js
export default function foo() {}

// bad-2.js
function foo() {}
export {foo as default}

[ljharb]

Why?? Default exports are the way things should operate most of the time.

The link says "named imports/exports promote clarity", which I find blatantly false - a single default export + the filename is the most clear thing in my experience. Additionally, "current tooling" doesn't "differ" in how to handle default exports; handling them is pretty clear.

[dead-claudia]

@ljharb

It's mostly a style preference - some people feel it's clearer/easier to maintain when you can't have effectively anonymous default exports. You can basically pick whatever name you want for default exports, but it's harder to do that with named ones, and some people prefer the increased structure.

For similar reasons, TSLint also has a similar rule that requires the imported and exported names to match.

[ljharb]

The filename is the name for a default export - they're never anonymous.

So far all the reasons I've heard are covered by "have the most basic unit tests you can think of", and "provide a non-useless filename" - both of which anyone using a linter is likely already doing.

I'm a -1 on having this rule; I think it's a very harmful style preference.

[dead-claudia]

I personally just like the consistency of only having one type of import used throughout. I do agree many of their claims (on the TSLint side) are invalid, though, and my reasoning differs from theirs.

• I find it easier to track files in larger projects when you have one less variable. One of my personal projects is literally 40k lines of code of plain ES5 + CommonJS.
• I prefer thinking of modules as boxes, not particular items within them, and default exports make it harder to keep this distinction. This is the difference between Java classes and Python modules - Java classes are single items with their own unique box, while Python modules are boxes with one or more items in them.

(I probably should've used this from the onset...)

[ljharb]

JS isn't Java or Python. A JS Module isn't a box; it's either a thing or it's not (default), and then separately, it has 0-N additional named exports. Most things should be things - not "not a thing, but has an extra thing".

[benmosher]

Default exports are the way things should operate most of the time.

Strong statement, @ljharb. I also have a tendency toward default exports but I agree with @isiahmeadows that it's a style thing. and I can imagine a team gelling around it and using a lint rule to enforce/communicate it with new hires/contributors.

I'd accept a PR implementing a no-default-export rule, but I wouldn't enable it by default anywhere.

[mordaha]

@ljharb JS module is not a thing. It is an abstraction for thinking about a project structure.

It is good to export default from library stored in npm, so consumers can choose any name they like (especially if you name you lib offensive or sexist!))

import NiceName from 'ugly-name-lib';

But in a project with naming conventions and rules it is a dangerous freedom.

What names the module exports - that names should be used, and when you refactored that names - you should refactor every name in consuming modules in your project.

Good rule for application projects. TS-team right.

[ljharb]

@mordaha in fact, it is a thing, ES2015 adds a parsing goal to the language for "Modules", which is where import and export come from. Short of that, the defacto standard for describing a "module" in JS is a file in the CJS (or AMD or UMD) format.

No, in fact they are wrong - you should never have to refactor the names in consuming modules. The choice of consuming name is up to the consumer and it should not impact the use of that module whatsoever.

If you want to restrict that freedom in your own consuming project, you can use linter rules to do so - it is simply user-hostile and incorrect for the providing module to attempt to force that preference upon you.

[vadimcoder]

If you want to restrict that freedom in your own consuming project, you can use linter rules to do so

@ljharb what is that wonderful rule you mentioned? Neither import/named nor import/default solves the problem.

[ljharb]

@vinogradov #936 is a PR to add a rule that can force this; but the "problem" you linked to imo is not a problem. A default export is never anonymous; the filename is its name.

A default export is what a module (a file) is, a named export is what a module has.