import/order: unresolved imports affecting the other

[aliaksandr-yermalayeu]

Unresolved imports automatically get "NaN" rank and also take part in finding out order violations.

Config:

{
    "rules": {
        "import/order": ["error", {
            "groups": ["builtin", "external", "internal", "parent", "sibling", "index"],
            "newlines-between": "ignore"
    }]
}

Example 1.

import a from "a.js"; //external import
import b from "b.js";
import d from "../d.js";
import e from "./e.js";
import c from "src/c.js"; //eslint-error

Example 2.

import a from "~/a.js"; //unresolved import
import b from "b.js";
import d from "../d.js";
import e from "./e.js";
import c from "src/c.js"; //no error

In the first example you may see that the order of imports is violated, because external import c goes after parent d. In the second one a becomes an unresolved due to ~ sign and starts interfering to plugin work.

I would say that unresolved imports should be ignored from the ordering process.

[atos1990]

I have a similar problem.
I'm use Webpack alias '~' in imports and during applying Order Rule such imports have NaN rank.
Maybe should add possibility to resolve Import type by Webpack alias?

[fdev]

Any update on this? import/no-unresolved still creates import/order errors.

[ljharb]

It’s not clear what the solution is to me. Ignoring them doesn’t necessarily work - does that mean they end up at the bottom? Unchanged, but other things can be moved across them?

A PR with tests would be welcome.

[fdev]

I would not ignore them.

Imports of type parent, sibling and index would remain the same. Even if the module path does not resolve, the path string still implies the type.
Imports of type builtin will always resolve; otherwise it's type internal or external.
That leaves internal and external. I assume you have to resolve the module path to tell the difference. In this case, when a path does not resolve, I would default to an interpretation of external as this is presumably more common than internal.

[ljharb]

That seems reasonable.

Of course, the best workaround for this is, make sure all your specifiers resolve - whether that's npm install, or configuring a resolver for this eslint plugin so it knows how to resolve your paths.