support export type named exports from typescript

[bradennapier]

Adds support so that export type named imports work with this plugin.

Resolves #1282

[coveralls]

Coverage remained the same at 97.862% when pulling 49af9d8 on bradennapier:feature/typescript-export-type into 3aefa79 on benmosher:master.

[coveralls]

Coverage increased (+3.2%) to 97.336% when pulling 4d93618 on bradennapier:feature/typescript-export-type into 206d676 on benmosher:master.

[coveralls]

Coverage increased (+3.2%) to 97.336% when pulling 4d93618 on bradennapier:feature/typescript-export-type into 206d676 on benmosher:master.

[coveralls]

Coverage increased (+3.2%) to 97.336% when pulling 4d93618 on bradennapier:feature/typescript-export-type into 206d676 on benmosher:master.

[ljharb]

Thanks! Can you please add some test cases?

[kjleitz]

@ljharb I was checking out the bug this fixes, and I'm just curious—what would a test case look like for this? I'm not sure I see any existing examples of specs for the other named declaration exports (just grepped for a few of them)

[bradennapier]

Yeah I’ve been meaning to ask that. In fact it would seem this somehow increased coverage although not sure how or why.

It’s a single case statement added and only covers a typescript type alias.

[ljharb]

The OP in the linked issue seems to have a test case?

[schmod]

Here's a commit that adds test-coverage. (GitHub won't let me PR it directly into @bradennapier's branch for some reason)

This turned out to be a weird one -- there are already tests for this functionality, but they were passing. The root issue actually appears to be a regression that only appears when switching from typescript-eslint-parser to @typescript-eslint/parser. I've updated the tests to run against both parsers.

typescript-eslint-parser was recently deprecated, but is widely-used to the extent where we should avoid deliberately breaking support for it in the short-term.

[ljharb]

@schmod thanks; i've added that commit to this branch.

[ljharb]

@schmod looks like tests are failing in eslint 2 and 3.

[schmod]

Huh. I'm guessing that we've uncovered an existing incompatibility between @typescript-eslint/parser and eslint 3.

Given that @typescript-eslint/parser has a peerDependency on eslint 5.x, I guess we'll just want to skip any tests using that parser on ESLint <5.

[schmod]

@ljharb schmod@8355aaf

[ljharb]

@schmod eslint 2 and 3 tests are still failing with that commit :-/

[schmod]

Huh, I'll have to dig in. They passed on my local machine.

[schmod]

Fun times. The tests pass on MacOS (using the dep-time-travel.sh script and all), but fail on Linux/Docker, and I have no clue why.

I've narrowed this down to @eslint-typescript/parser merely being installed (which shouldn't matter?!). I'll add a workaround to dep-time-travel to remove the new parser when it isn't being used by the tests (ie. on ESLint <5), but this is a pretty spooky bug, TBH.

Commit: 1914fd6

[brian-tran-dev]

Does this one also include export import SomeEnum = SomeModule.SomeEnum;