Consider removing import/no-anonymous-default-export

[sholladay]

The rule import/no-anonymous-default-export was added in PR #472.

I've been running into a lot of cases where this rule is annoying. For example, many of my apps have a lib/routes directory that contains HTTP server routes, wherein each file exports a plain object that defines the method, path, handler, etc. of that route.

export default {
    method: 'GET',
    path: '/',
    // ...
};

XO wants me to change this code to something like:

const route = {
    method: 'GET',
    path: '/',
    // ...
};
export default route;

But that change brings no real benefit. It doesn't improve the searching or debugging of the codebase because this same route identifier would be used for all routes, so it remains ambiguous.

I could disambiguate each route by giving it a unique name like const getSlashRoute = ... but I'm just not going to bother with that. It's way too verbose for most routes.

Additionally, and more importantly in my opinion, it's not exactly equivalent. One nice thing about export default {} is that it's completely static. We know for sure that the object is exported as-is without being mutated. Whereas, with export default route, it's possible the route is mutated within the module before being exported, which I really want to avoid.

In summary, I feel that this rule has too high of a pain/reward ratio. Would you be willing to remove it or at least relax it's configuration? I would probably be fine with enforcing this rule for functions, for example. I usually like to name my default export when it is a function, because the name can be defined inline with export default function foo() { and functions tend to be much more unique. But for objects and other data-like exports, it's often just too much of a hassle.

[sindresorhus]

I agree, it should only apply to functions.

[fregante]

I disagree, the rule is helpful for IDEs to decide what to call imports. export default 42 doesn't tell me what 42 is.

And no, it can't always be figured out from the filename because it may be index.js. Also XO doesn't include filenames/match-exported specifically because the default might not need to match the preferred filename.

If I type lif| in my editor it will know exactly that I'm referring to the const life = 42 I have in index.js