Add allowAliasing option to import/no-default-export

[k-yle]

The import/no-default-export rule has two parts

• banning syntax like export default function () {} and export default foo;
• banning aliased default exports (e.g. export { foo as default } from "./foot";)

In our use case, we only want to ban the first syntax, but allow aliased importing. This is because we use React lazy/suspense which requires default exports to be used.

This PR adds an allowAliasing option to allow just aliased exports

Hope this PR is okay. Haven't worked with eslint plugins much

[coveralls]

Coverage increased (+0.002%) to 97.741% when pulling abbaabb on k-yle:master into 92caa35 on benmosher:master.

[ljharb]

If aliasing is allowed, what's the point of disallowing default exports at all?

(note that I severely disagree with this rule existing, as I think a default export is what a module is, and a named export is something a module has, and most modules should be something)

[k-yle]

If aliasing is allowed, what's the point of disallowing default exports at all?

In general we don't want to allow default exports, but aliassing should be allowed for when we need to use React's code-splitting.

[ljharb]

Right, but why does "React.lazy requires default exports" not suggest that you should use default exports? Aliasing would just be a hack for using the wrong kind of export.

[k-yle]

within the folder we still want to use named imports. We find named imports much more useful. If something outside of that folder wants to lazy load it, the index.js file re-exports it as a default export

[ljharb]

In that case, you could use overrides to disable this rule for **/index.js, no option required?

[k-yle]

for our specific case that could work. but is there a harm in adding an option?

[ljharb]

There's always harm in adding things :-) it's just got to be weighed against the benefit. Since a) this rule imo should never have existed in the first place, and b) your use case is trivially solved with overrides, unless there's a use case for an option it doesn't seem worth it.

[ccjmne]

@ljharb Hey!

I was about to suggest adding an option with a glob pattern for files to ignore... like import/no-extraneous-dependencies allows, for instance, and didn't know of the overrides you just mentioned.
Thanks for that! You just got me sorted :)

--

I'm curious as to why you think import/no-default-export should never have existed, though?

I favour named exports because they allow me to more easily refactor/auto-import bits and pieces from other parts of the project, and came to believe that now that ES Modules are pretty commonplace and well-established, maybe I could simply enforce avoiding default exports consistently, except when dealing with external libraries that require a "default" export.

I don't want to argue or anything, I genuinely want to know what your take on this matter is!
Maybe you figure that "enforcing" named exports in code that is not exposed as part of a library or anything isn't a worthwhile matter, maybe you feel that default exports are just simpler and should be preferred (after all, even conceptually, that's definitely true, and until pretty recently I was thinking just that 😂) or maybe it's something else altogether? For instance, the mere fact that many external tools likely always will be looking for a default export... may be sufficient to discard the idea of the import/no-default-export rule.

Welp, so much for asking a quick question, it already looks like a wall of text :')

Again, I'm just asking for you to elaborate, out of curiosity! Thanks for mentioning ESLint's overrides :)

[ljharb]

@ccjmne
A default export is what a module is, a named export is something a module has. Most modules should be something.

It's a shame that IDEs have failed to implement the same autocorrect and auto-refactor tooling for default imports - there's zero technical reason why this is difficult that I'm aware of - but I'd encourage you not to alter how you architect your codebase solely based on the momentary flaws of your tooling.