no-named-as-default warn/error when value is both named export and default export

Example (here I want to export everything from one or merge more files, then set a default export):

// filename is: ./file/index.js
export * from './file'; // this contains export const file = ...
export * from './anotherfile';
export {file as default} from './file';

// filename is ./main.js
import file from './file';  // import from directory file, resolving to ./file/index.js
/*
 Line above gives warn/error:
 Using exported name 'file' as identifier
 for default export.eslint(import/no-named-as-default)
*/

[ljharb]

This is intentional; since there’s a named export named “file”, the rule won’t let you use that name for the default when importing.

[markmsmith]

What about a simpler example:

// Bar.js

/** @private visible for testing */
export const foo = 42;

/** @private visible for testing */
export class BarHelper{}

export class Bar {
  
}

export default Bar;

// Bar.test.js

import {foo, Bar, BarHelper} from '../src/Bar.js'
// write tests against Bar

// index.js

// no-named-as-default error here
import Bar from './Bar.js';
// use Bar for real
const bar = new Bar();

In this case it will complain about the Bar import in index.js, even though it's referring to the exact same thing. We've used this pattern in a number of projects to indicate that the default export is the public contract for the main thing you're supposed to use, but individual named exports would be used by unit tests.

@markmsmith yeah, your example is more clear. Still I find that the issue triggering the warn/error of eslint is annoying for these use cases

[ljharb]

That makes no sense to me why you’d double-export Bar. Tests should be testing the same thing production uses - which in your case is the default export.

Yeah, but I'm making a npm package and each "submodule" folder as an index file that re-exports everything + a default. It was easier to do it and have most of the "submodule" defaults only accessible by name (not default) outside of the npm package

[Nokel81]

I have run into this too when trying to consume some npm packages. For instance the https://www.npmjs.com/package/abort-controller has the following exports:

export default AbortController
export { AbortController, AbortSignal }

It would be nice if doing import AbortController from "abort-controller"; wouldn't warn because it is the same item.

I prefer keeping the rule in place so that if a package does the following:

export default foo;
export { bar, bat };

I do get a warning if I do import bar from "some-package"

[ljharb]

While I continue to think that it's utter nonsense to export the same value twice, I agree that in that case only, the rule should not warn.

I'd be happy to accept a PR that handled that (perhaps under an option)

[Nokel81]

Fair enough, it does seem like a really bad practice and I think it should be under an option.

[akwodkiewicz]

I can try this. I have lots of "false positives" for

import userEvent from '@testing-library/user-event';

I'd like to get rid of. Forking the repo right now.