[TypeScript] Support default exports in TSExportAssignment.

[joaovieira]

Allows TypeScript export assignments of default identifiers and/or mixed merged declarations. E.g.:

declare const foobar: number;
export = foobar;

declare function foobar(): void;
declare namespace foobar {
  type MyType = string
}
export = foobar;

import { foobar } from './module';
export = foobar;

// No longer reports missing default export
import foobar, { MyType } from './foobar';

Fixes: #1527

[joaovieira]

I'm not sure about n here. Would it be worth looking through the m.imports to see if any matches the exported name? We don't do that on regular exports. E.g.:

import { test } from './test';
export { foo }; // all good...

[coveralls]

Coverage increased (+2.5%) to 97.815% when pulling 381267a on joaovieira:extend-ts-export-assignment into 9516152 on benmosher:master.

[coveralls]

Coverage decreased (-0.4%) to 96.151% when pulling 86d2eff on joaovieira:extend-ts-export-assignment into 112a0bf on benmosher:master.

[coveralls]

Coverage decreased (-0.4%) to 96.151% when pulling 86d2eff on joaovieira:extend-ts-export-assignment into 112a0bf on benmosher:master.

[coveralls]

Coverage decreased (-0.4%) to 96.151% when pulling 86d2eff on joaovieira:extend-ts-export-assignment into 112a0bf on benmosher:master.

[coveralls]

Coverage decreased (-0.4%) to 96.151% when pulling 86d2eff on joaovieira:extend-ts-export-assignment into 112a0bf on benmosher:master.

[JounQin]

It should read about esModuleInterop option or add an equal option for this plugin instead of hard coding the logic IMO.

[ljharb]

@JounQin can you elaborate?

TS's module system is broken without synthetic imports and esModuleInterop enabled; I'm completely comfortable telling people they need to enable those if they want stuff to work properly.

[Maxim-Mazurok]

What a great PR! I was searching for a solution all day, finally gave up and started to dig into the sources. Strangely enough, this PR didn't come up while I was searching for similar issues.
So, I started coding basically the same thing: #1689

@JounQin I agree with you, in my PR I'm reading from tsconfig.json. But, there might be multiple tsconfigs and they might include/exclude specific files. So, the best approach would be to first, figure out which tsconfig is covering file where the import is made and then check if that config has esModuleInterop enabled.
Here's an example of code from eslint-import-resolver-typescript that does kind of similar thing:

mappers = configPaths!
  // turn glob patterns into paths
  .reduce<string[]>(
    (paths, path) => paths.concat(isGlob(path) ? globSync(path) : path),
    [],
  )
  .map(loadConfig)
  .filter(isConfigLoaderSuccessResult)
  .map(configLoaderResult => {
    const matchPath = createMatchPath(
      configLoaderResult.absoluteBaseUrl,
      configLoaderResult.paths,
    )

    return (source: string, file: string) => {
      // exclude files that are not part of the config base url
      if (!file.includes(configLoaderResult.absoluteBaseUrl)) {
        return undefined
      }

      // look for files based on setup tsconfig "paths"
      return matchPath(source, undefined, undefined, extensions)
    }
  })

That being said, we should either do the right thing and figure out how to handle complex cases. Or, we can do the simple thing and only cover simple case (only root tsconfig) or introduce new leg in parserOptions that will also act globally but will be more explicit than assuming that everybody has only one tsconfig.

Also, I can't disagree with @ljharb about assuming that everyone uses esModuleInterop nowadays. It seems to be a pretty popular flag to use. And in this case, I would be very happy to see this PR merged, thanks!

[julien1619]

Hey! Here declarations is undefined unless type === 'VariableDeclaration' so it crashes the linter in some cases. I'll create another PR to fix it.

[ljharb]

Thanks!

[richard-lopes-ifood]

Nice fixing 🚀! When is it going to be released?