Using getSymbolAtLocation on side effect import's module specifier produces TS2307 diagnostic

[ark120202]

TypeScript Version: 3.7.x-dev.201xxxxx

Search Terms:

Code

const ts = require('typescript');

const files = {
  'main.ts': 'import "./module";',
  'module.d.ts': 'declare const foo: any;'
};

const host = ts.createCompilerHost({})
const originalReadFile = host.readFile;
host.readFile = (fileName) => files[fileName] || originalReadFile(fileName);

const program = ts.createProgram({ host, rootNames: ['main.ts'], options: { types: [] } });
const typeChecker = program.getDiagnosticsProducingTypeChecker();
const sourceFile = program.getSourceFile('main.ts');

typeChecker.getSymbolAtLocation(sourceFile.statements[0].moduleSpecifier);

console.log(program.getSemanticDiagnostics());

Expected behavior:

getSemanticDiagnostics to return an empty array

Actual behavior:

TS2307: Cannot find module './module'.

Removing getSemanticDiagnostics or using getTypeAtLocation instead does not produce a diagnostic.

Similarly to #34913, it's observable only with diagnostics producing type checker.

Playground Link:

Related Issues: #34913

[RyanCavanaugh]

module.d.ts is not a module file

[ark120202]

Yes, but it's referenced in the context of a side-effect import, which generally isn't checked. Usually it's not an issue because TypeScript itself doesn't try to get it's symbol, and API consumers don't have an access to diagnostics producing type checker, but they would have it with #28584

[typescript-bot]

This issue has been marked as 'Question' and has seen no recent activity. It has been automatically closed for house-keeping purposes. If you're still waiting on a response, questions are usually better suited to stackoverflow.

[ark120202]

@RyanCavanaugh could you please take another look on this issue? It's not supposed to be a question.