Rule proposal: `no-named-default`

[fisker]

Description

During refactoring, eg:

// We don't need `foo` at first.
doThingsWithoutFoo();

export {default as foo} from 'foo';

import {default as foo} from 'foo'; // Didn't mean to import like this, but changed from previous version

// We need `foo` now
doThingsWithFoo();
export {foo}

Fail

import {default as foo} from 'foo';

import {default as foo, bar} from 'foo';

Pass

import foo from 'foo';

import foo, {bar} from 'foo';

Additional Info

Should we check export?

Fail

export {foo as default};

Pass

export default foo;

[fisker]

It seems there is already a rule import/no-named-default.

[fisker]

But it doesn't have an auto-fix, let's make our own?

[sindresorhus]

Should we check export?

Yes

But it doesn't have an auto-fix, let's make our own?

👍

[fisker]

@B2o5T You don't like the idea, or don't like that we are making a new version of import/no-named-default. Can you share your thought?

[fisker]

For implemention details:

This case

import foo, {default as bar} from 'foo';

Should we report? Maybe user have a good reason to do that.

import foo, {default as bar} from 'foo';

function a({foo}) {
   // For a good reason that he can't use `foo` here.
   bar(...)
}

The following seems not an improvement.

import foo from 'foo';
const bar = foo;

function a({foo}) {
   // For a good reason that he can't use `foo` here.
   bar(...)
}

Maybe we should report and ask user to use eslint-disable?

[sindresorhus]

Should we report? Maybe user have a good reason to do that.

Yes. We should report. That's just a confusing pattern. Variable reassignment (const bar = foo;) is much clearer.

[fisker]

Okay, report but not fixable.

[dimaMachina]

@B2o5T You don't like the idea, or don't like that we are making a new version of import/no-named-default. Can you share your thought?

I don't like the idea because there is already an existing rule.

note that similar extending existing rule with auto fix no-negated-condition is fine due to big refactoring in codebases

[fisker]

I don't like to do this either, but I like this rule to have auto-fix.

Are you suggesting to contribute to eslint-plugin-import instead?

[dimaMachina]

I don't like to do this either, but I like this rule to have auto-fix.

Are you suggestion to contribute to eslint-plugin-import instead?

You can try to propose implementing autofix in eslint-plugin-import

[fisker]

Main reason I didn't try that.

That plugin is not actively maintained, the rule only covers some of what's mentioned here, and the plugin is slow as it traverses all the imports and their graph.

Quote from #1067 (comment), and I agree with that.

I sent one PR there before and the development experiences are bad, as they even need support Node.js v4 and ESLint v2

[sindresorhus]

Accepted