github-pages-deploy-action/node_modules/eslint-plugin-import/docs/rules/no-named-as-default-member.md

import/no-named-as-default-member

Reports use of an exported name as a property on the default export.

Rationale: Accessing a property that has a name that is shared by an exported name from the same module is likely to be a mistake.

Named import syntax looks very similar to destructuring assignment. It's easy to make the (incorrect) assumption that named exports are also accessible as properties of the default export.

Furthermore, in Babel 5 this is actually how things worked. This was fixed in Babel 6. Before upgrading an existing codebase to Babel 6, it can be useful to run this lint rule.

Rule Details

Given:

// foo.js
export default 'foo';
export const bar = 'baz';

...this would be valid:

import foo, {bar} from './foo.js';

...and the following would be reported:

// Caution: `foo` also has a named export `bar`.
// Check if you meant to write `import {bar} from './foo.js'` instead.
import foo from './foo.js';
const bar = foo.bar;

// Caution: `foo` also has a named export `bar`.
// Check if you meant to write `import {bar} from './foo.js'` instead.
import foo from './foo.js';
const {bar} = foo;