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.