order/newline-after-import: Add support for TypeScript's "export import"

[be5invis]

This PR adds support for TypeScript's "export import", typically used to re-export things.
In current eslint-plugin-import they are treated as imports rather than exports.
Related: #1829.
cc. @ljharb

[coveralls]

Coverage increased (+0.004%) to 97.895% when pulling 2962628 on be5invis:be5invis-add-test-for-export-import-typescript into 4a38ef4 on benmosher:master.

[ljharb]

Thanks!

[be5invis]

@ljharb Hah, these tests reveal a bug in newline-after-import. I will file another issue.

[ljharb]

lol, thanks :-) we can just turn this PR into the fix for it.

[be5invis]

Add @manuth

@ljharb I may not able to create a fix because I cannot get eslint-plugin-import's testing work on my machine, it always ends with these errors:

npm run test

> eslint-plugin-import@2.21.2 pretest Z:\eslint-plugin-import
> linklocal

tests\files\order-redirect
resolvers\webpack
tests\files\symlinked-module
tests\files\order-redirect-scoped
utils
resolvers\node

Linked 6 dependencies

> eslint-plugin-import@2.21.2 test Z:\eslint-plugin-import
> npm run tests-only


> eslint-plugin-import@2.21.2 tests-only Z:\eslint-plugin-import
> npm run mocha tests/src


> eslint-plugin-import@2.21.2 mocha Z:\eslint-plugin-import
> cross-env BABEL_ENV=test nyc -s mocha "tests/src"

internal/modules/cjs/loader.js:985
  throw err;
  ^

Error: Cannot find module 'Z:\eslint-plugin-import\node'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}
events.js:288
      throw er; // Unhandled 'error' event
      ^

Error: spawn nyc ENOENT
    at notFoundError (Z:\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:11:11)
    at verifyENOENT (Z:\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:46:16)
    at ChildProcess.cp.emit (Z:\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:33:19)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
Emitted 'error' event on ChildProcess instance at:
    at ChildProcess.cp.emit (Z:\eslint-plugin-import\node_modules\cross-spawn\lib\enoent.js:36:37)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12) {
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn nyc'
}

[manuth]

@be5invis for getting this repo to work on a windows machine I recommend you to use "Windows Subsystem for Linux" aka. WSL (VSCode provides extensions for developing projects inside WSL.

If you don't want to use WSL, you can upgrade the nyc dependency:

npm install --no-save nyc@latest

After this, tests should work fine on windows.

[manuth]

@be5invis do I understand correctly, that your goal is, that export import statements basically are ignored by the import/order rule?

[be5invis]

@manuth
I think import/order ignores "object imports" so I added similar ignoring to import/newline-after-import.
Upgrading nyc fixed the test runner so I can now make a fix 🥂.

[manuth]

Recent changes in #1823 cause them to not be ignored by import/order 😅
Looks like there's more work to be done for supporting TSImportEqualsDeclaration...

[manuth]

Shall we discuss TSImportEqualsDeclarations right here or should I create a separate PR?

[be5invis]

@manuth Ah I understand what you mean...
There's also a isExport property for TSImportEqualsDeclarations. We can use that to ignore export imports.

[manuth]

Exactly... it's not just this, sadly...
As we have learned, there are two different kinds of TSImportEqualsDeclarations: Object-literal imports and module-imports.
Each of them can either be imported or imported and exported both at the same time:

// Modules
import fs = require("fs");
// or
export import fs = require("fs");

import { ESLint } from "eslint";
// Object-literals
import LintResult = ESLint.LintResult;
// or
export import LintResult = ESLint.LintResult;

Problems About Exports

As you have brought up in issue #1829, export imports can occur anywhere (that is in namespaces, in nested contexts etc.).
Imo, this can only be solved by letting import/order ignore export imports.

Problems About Object-Literals

My last changes in mentioned PR caused object-imports to be forced to be alphabetized as well.
I've noticed, that this is a bad behavior, too, as object-imports might depend on each other:

import A = ESLint;
import LintResult = A.LintResult; // Reports an error because "ESLint" > "A.LintResult"

I don't really know what to do about it... either we could set the name of each object-import to "", which causes any order of object-imports to be allowed.
Otherwise we could just let import/order ignore object-imports as well.

Also there's more to be done about TSImportEqualsDeclarations. I think we should add support for this sort of import-expressions for all the other rules as well.

[be5invis]

@manuth Agree. We could file other work items for further support of these.

[manuth]

Alright! What about fixing object-imports and export imports?
Shall we just ignore them in the import/order-rule?

[manuth]

I've added some comments here and there where there are some changes to be applied.