Should we implement eslint rule: import/no-default-export?

[ThijsTyZ]

Maybe we should also consider this rule: import/no-default-export. I never worked with that rule enabled so I don't know the downsides, but sometimes I run into problems when refactoring in the IDE that names are not updated because of the default export. I don't know if there is an added value for default exports over named exports.

Originally posted by @hjeti in mediamonks/frontend-coding-standards#6 (comment)

[psimk]

yes; can I add it now ? :)

[ThaNarie]

I suggest looking at your codebases, and see how often this is still used.

Maybe not in the normal "components" that you write, but more in other supported files (often around tooling).

• Especially files that are loaded as "configuration" dynamically are expected to have a single default export (like webpack, monck, plop, etc)
• So do story files (their meta)

Are we okay with either manually configuring them all, or constantly disabling those linting rules there?

[psimk]

We use it often, because we are used to it. The vue-skeleton even has the opposite rule - prefer default export, when there's a single export.

We can enable this rule only for the /src directory, excluding *.stories.ts files. This would having to deal with it in configuration files.

[ThaNarie]

We use it often, because we are used to it

Sorry, I meant to say; legitimate use (according to our proposed conventions)

We can enable this rule only for the /src directory, excluding *.stories.ts files.

That would be a sound option.

👿 Are we okay with "hardcoding" the src folder in our linting rules? File extensions are pretty universal, but folder names or their location in projects could change?

[leroykorterink]

Default exports are used to export components in pages in the NextJS framework. I'm updating the configuration to disallow unnamed default exports, default exports will still be allowed.