Add import/no-default-export rule

[umpox]

Thoughts on this?

• We're already discouraging their usage in some of our documentation
• Our usage of default exports is fairly low and this will help catch issues before they hit PR

Further reading on why default exports are bad

[tjkandala]

Great idea! How should we handle our webpack config exports?

[umpox]

Great idea! How should we handle our webpack config exports?

It's a fair point, we're going to run into tools or libs (hence the *.d.ts exclusion) that still make use of default exports, although it should be relatively rare that there won't be a better solutions to work with these. For example, we can still use module.exports with webpack, which is still a better solution than default, or even we could export const each part of the webpack config. These particular exports are actually passed around in our code and are used to call webpack directly as a function, so these should work fine as named exports.

[felixfbecker]

@umpox I see you made this a draft PR, do you not want review on it yet? (I only stumbled across this by accident)

[umpox]

@felixfbecker Left it as a draft as I need to make changes to other repos before the build can pass, I guess there's no reason this can't be reviewed now though! Will change

[sourcegraph-buildkite]

🎉 This PR is included in version 0.21.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀