"no-named-as-default" should be changed to lessen false positives from 3rd party modules

[Zamiell]

The "no-named-as-default" rule throws some false positives.

Consider an error on the following line of code, which invokes the popular klaw-sync library:

import klawSync from "klaw-sync";

This errors because the module is not smart enough to figure out that variable names cannot have hyphens.

The following is a similar error from TypeScript:

import ts from "typescript";

While the "no-named-as-default" rule does seem to provide value to a codebase, it is undesirable to have to add "eslint-disable-line" entries across codebases whenever 3rd-party libraries need to be invoked like this. I feel that 3rd party libraries of this nature are common enough such that many users will disable the rule altogether, which is an unfortunate outcome.

Can we add an option to the rule to ignore all 3rd party libraries (from e.g. "node_modules" or whatnot)? Or is there some other good way to reduce this kind of false positive?

Conceptually, this lint rule is about preventing bugs from creeping in to the codebase when files with default exports are refactored/renamed. Subsequently, I do not think that this class of error applies to a 3rd party modules, since the default name correlates directly to the name of the dependency that is tied to the "package.json" file. Subsequently, I would argue that ignoring this kind of thing should be the default behavior.

[controversial]

I have a lot of false positives for this rule related, I think, to import-js#1594

The issue with a lot of pacakges is that they export the same value as a named import and as a default import:

export const z = /* ... */
export default z

This leads to errors for common imports like:

import React from 'react';
import z from 'zod';
import classNames from 'classnames';

It would be great if there could be a way for this rule to detect cases where the default export refers to the same value as the named export, and avoid reporting the error in this special case

[SukkaW]

import z from 'zod';

@controversial This fails because you can do both:

import z from 'zod';
import { z } from 'zod';

And the rule no-named-as-default prefers the later.

[controversial]

@SukkaW Thanks for explaining! My understanding is that the intention of the no-named-as-default rule is to catch mistakes like

import useState from 'react';

, where the user intends to make a named import (import { useState } from 'react';) and accidentally imports a different value instead.

The import React from 'react'; case feels slightly different to me. When a module contains a “double” default/named export of the same value—something like the following:

export const React = /* ... */
export default React

—the default import is identical to the named import. It’s not useful to warn the user “you might be failing to access the named export you intended,” because the import they are in fact accessing is identical to the named export they’re being warned about.

I think the rule would become much more useful if there were, at minimum, an option on the rule to configure whether this case produces a lint error!

[SukkaW]

The issue is fixed in #133 and will be included in the next release.

[SukkaW]

eslint-plugin-import-x@4.1.1 has been released!

[controversial]

@SukkaW it looks like eslint-plugin-import just merged a fix for the case I was describing above, which I believe is slightly different than the case that was addressed here

[akwodkiewicz]

Hey, I'm the author of the PR mentioned above by @controversial. I just got notified about this issue.

You have to be aware that my fix works only for the imports where the objects are re-exported from the file you import.

The API I worked with (probably?) does not give me tools to verify if the named export is equivalent to the default export. In a case of a re-export I'm at least able to check the path of the module and the name of the imported thing. In a case of object definition in the imported file I'm clueless.

So, if a library you're having problems with (lots of false positives) happens to export something as a named and a default export from a barrel file, my fix will work. But otherwise, it won't.