Re-exporting a default export that doesn't exist with allowSyntheticDefaultExports true causes assert failures in getDefaultExportInfoWorker

[dawnmist]

Ever since VSCode 1.28.x started using Typescript 3.x, we've been unable to use code completion or auto imports due to the assert within "getDefaultExportInfoWorker" where it validated that the alias for a default export was set. This would cause an incomprehensible error within getCodeFixes and completionEntryDetails as reported in the comment microsoft/vscode#61660 (comment)

Errors with line numbers as reported in typescript 3.3.0-dev.20190101:

[Error  - 6:20:50 PM] 'completionEntryDetails' request failed with error.
Error processing request. Debug Failure.
Error: Debug Failure.
    at Object.assertDefined (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:1482:24)
    at getDefaultExportInfoWorker (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111582:80)
    at getDefaultLikeExportInfo (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111563:24)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111360:35
    at forEachExternalModule (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111703:21)
    at getAllReExportingModules (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111355:13)
    at Object.getImportCompletionAction (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111341:31)
    at getCompletionEntryCodeActionsAndSourceDisplay (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:96475:33)
    at Object.getCompletionEntryDetails (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:96439:30)
    at Object.getCompletionEntryDetails (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:117739:35)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:125895:57
    at Object.mapDefined (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:601:30)
    at IOSession.Session.getCompletionEntryDetails (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:125893:33)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:124879:61)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126357:88
    at IOSession.Session.executeWithRequestId (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126348:28)
    at IOSession.Session.executeCommand (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126357:33)
    at IOSession.Session.onMessage (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126379:35)
    at Interface.<anonymous> (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:127640:27)
    at emitOne (events.js:116:13)
    at Interface.emit (events.js:211:7)
    at Interface._onLine (readline.js:282:10)
    at Interface._normalWrite (readline.js:424:12)
    at Socket.ondata (readline.js:141:10)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20)
[Error  - 6:20:51 PM] 'getCodeFixes' request failed with error.
Error processing request. Debug Failure.
Error: Debug Failure.
    at Object.assertDefined (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:1482:24)
    at getDefaultExportInfoWorker (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111582:80)
    at getDefaultLikeExportInfo (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111563:24)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111546:35
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111690:21
    at forEachExternalModule (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111703:21)
    at forEachExternalModuleToImportFrom (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111688:13)
    at getExportInfos (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111544:13)
    at getFixesInfoForNonUMDImport (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111530:57)
    at getFixesInfo (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111471:50)
    at Object.getCodeActions (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:111233:28)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:108932:121
    at Object.flatMap (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:504:25)
    at Object.getFixes (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:108932:23)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:118039:35
    at Object.flatMap (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:504:25)
    at Object.getCodeFixesAtPosition (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:118037:23)
    at IOSession.Session.getCodeFixes (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126188:64)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:124994:61)
    at /home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126357:88
    at IOSession.Session.executeWithRequestId (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126348:28)
    at IOSession.Session.executeCommand (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126357:33)
    at IOSession.Session.onMessage (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:126379:35)
    at Interface.<anonymous> (/home/dawnmist/app/node_modules/typescript/lib/tsserver.js:127640:27)
    at emitOne (events.js:116:13)
    at Interface.emit (events.js:211:7)
    at Interface._onLine (readline.js:282:10)
    at Interface._normalWrite (readline.js:424:12)
    at Socket.ondata (readline.js:141:10)
    at emitOne (events.js:116:13)
    at Socket.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)
    at Socket.Readable.push (_stream_readable.js:208:10)
    at Pipe.onread (net.js:594:20)

The error had been occurring for typescript 3.0.x, 3.1.x, 3.2.x, 3.3.x. Typescript 2.9.2 was not throwing the assert failures, so VSCode would function with a workspace setting of typescript 2.9.2 (though losing other functionality that depended on typescript 3.x) & code would still compile without issues in all typescript versions.

The assert and stack trace provide no details with which to identify where the problem that is causing the assert failure is coming from.

These errors then break both code-completion information (file locations, documentation, etc) and auto-imports in VSCode 1.28.x-1.30.x. Several interrelated bugs have also been causing issues for those items, resulting in the original issues being closed as fixed when some people were still having problems without being able to identify why.

After spending two days tracing through the issue:

• I started with checking whether the issue occurred in a new react project that had defined the same list of node_modules, since when the issues with code completion/auto imports in VSCode first started there was some discussion that some npm modules could cause similar crashes in the typescript version being used at that time. I found that VSCode worked properly & there were no assertion errors thrown then, indicating that the error was somewhere within our project code itself.
• I then tested turning off allowSyntheticDefaultExports in the original project since the assert being failed appeared to be when looking for an aliased default export. This then required alteration of imports for lodash, moment, several react component libraries, etc, in order to allow the existing code to compile again with allowSyntheticDefaultExports turned off.
• About 95% of the way through dealing with the import issues from turning off allowSyntheticDefaultExports, I finally received an error message that one of our files was trying to re-export the default export from another file that did not actually contain a default export.
• After completing turning off allowSyntheticDefaultExports and removing the faulty re-export in our file, the assert failures inside getDefaultExportInfoWorker no longer occurred.
• I then turned allowSyntheticDefaultExports back on, and undid all changes except the bugfix for the faulty re-export in our file, and the assert failures inside getDefaultExportInfoWorker still no longer occurred.

When in ES6 mode with allowSyntheticDefaultExports, no warning/error is produced for re-exporting a default export that doesn't exist. As such, the only way the user knows that there is an error somewhere (but with no information about where) is when the typescript language server starts throwing assert failures that break VSCode's code completion & auto-import functionality.

TypeScript Version: 3.0.x, 3.1.x, 3.2.x, 3.3.0-dev.20190101

Search Terms: default export, allowSyntheticDefaultExports, alias, getDefaultExportInfoWorker, getCodeFixes, completionEntryDetails.

Code
componentA/A.tsx

export interface AProps {
  message: string;
}

export const A = (props: AProps) => <h1>{props.message}</h1>;

componentA/index.tsx

export { default } from './A';
export * from './A';

Expected behavior:
Typescript should identify and report that the export { default } line in componentA/index.tsx is an error regardless of whether allowSyntheticDefaultExports is true or false.

Actual behavior:
When allowSyntheticDefaultExports is true, no error is reported and the typescript language server instead throws assertion failures in getDefaultExportInfoWorker that result in breaking VSCode's code completion info and auto-import functionality.

Related Issues:
microsoft/vscode#61660
#28149
#27636
#27640

[weswigham]

Typescript should identify and report that the export { default } line in componentA/index.tsx is an error regardless of whether allowSyntheticDefaultExports is true or false.

This is a slightly incorrect assumption. The allowSyntheticDefaultExports flag lets the checker assume that a synthetic default may exist for interop purposes (ie, systemjs's module loader makes one), even if one is not declared. The issue is most definitely the language service not handling the potential symbol (or lack of some part thereof?) for a synthetic default correctly.

[kumarashwin]

Thank you so much for your investigation! Finally got led to this very post which allowed me to solve the issue of import suggestions not working.