TypeScript LSP Cannot Resolve lib.dom.d.ts Despite File Existing

[s19514tt]

🔎 Search Terms

typescript lsp lib.dom.d.ts not found
typescript cannot resolve lib.dom.d.ts
typescript language server missing global types
typescript global types missing
cannot find global type 'Array'
typescript lib.dom.d.ts fileExists but not found
typescript LSP missing standard library

🕗 Version & Regression Information

This issue occurs in all versions from 4.8.4 to the latest.

⏯ Playground Link

No response

💻 Code

import * as ts from "typescript";
import * as path from "path";

// TypeScript Language Service Host
const tempFilePath = path.join(__dirname, "temp.ts");
let tempScriptContent = "";
let scriptVersion = 0;

const tsHost: ts.LanguageServiceHost = {
  getScriptFileNames: () => [tempFilePath],
  getScriptVersion: () => scriptVersion.toString(),
  getScriptSnapshot: (fileName) =>
    fileName === tempFilePath ? ts.ScriptSnapshot.fromString(tempScriptContent) : undefined,
  getCompilationSettings: () => ({
    module: ts.ModuleKind.CommonJS,
    target: ts.ScriptTarget.ES2020,
    strict: true,
    lib: ["lib.dom.d.ts"],  // Standard TypeScript library
    allowJs: true,
    noEmit: true,
  }),
  getDefaultLibFileName: (options) => ts.getDefaultLibFilePath(options),
  readFile: (fileName) => ts.sys.readFile(fileName),
  fileExists: (fileName) => ts.sys.fileExists(fileName),
};

const tsService = ts.createLanguageService(tsHost);

console.log(tsService.getCompilerOptionsDiagnostics());

The full code is available here:
server.ts in lunas-dev/lunas-vscode

🙁 Actual behavior

I am developing a VS Code extension that integrates TypeScript as part of my custom language.
To achieve this, the language server for my extension internally starts a TypeScript language server,
acting as a proxy to leverage TypeScript's features.

In this implementation, the TypeScript standard library (e.g., lib.dom.d.ts) needs to be properly loaded,
so I have added lib.dom.d.ts to the lib setting. However, since the standard library is not being recognized,
global objects like console and Window cannot be used within the language server.

Upon investigation, TypeScript reports the error lib.dom.d.ts cannot be found even though the file physically exists.

Error message from console.log(tsService.getCompilerOptionsDiagnostics());:

{
file: undefined,
start: undefined,
length: undefined,
code: 6053,
category: 1,
messageText: {
messageText: “File ‘/Users/username/.vscode/extensions/lunasdev.lunas-0.0.1-beta.1/node_modules/typescript/lib/lib.dom.d.ts’ not found.”,
category: 1,
code: 6053,
next: [Array]
},
relatedInformation: undefined
}

% ls /Users/username/.vscode/extensions/lunasdev.lunas-0.0.1-beta.1/node_modules/typescript/lib/lib.es2020.full.d.ts
/Users/username/.vscode/extensions/lunasdev.lunas-0.0.1-beta.1/node_modules/typescript/lib/lib.es2020.full.d.ts

However, immediately after this error message, a debug log confirms that fileExists() correctly detects the file:

[DEBUG] fileExists("/Users/username/.vscode/extensions/lunasdev.lunas-0.0.1-beta.1/node_modules/typescript/lib/lib.dom.d.ts") → true

This creates an inconsistency where TypeScript's diagnostics claim that the file does not exist, but the file system check confirms that it does.

Key inconsistencies:

1. TypeScript reports that lib.dom.d.ts is missing.
2. Immediately after, fileExists() confirms that the file is actually present.
3. The default library file (lib.es2020.full.d.ts) is only resolved after getCompilerOptionsDiagnostics() runs.

This suggests that TypeScript is either:

• Performing a file existence check before the library paths are properly initialized.
• Using an outdated cached state when diagnosing missing files.

🙂 Expected behavior

TypeScript should correctly resolve lib.dom.d.ts when specified in lib: ["dom"] or lib: ["lib.dom.d.ts"] within getCompilationSettings().

Expected behavior:

1. No false missing file errors

   • TypeScript should not report lib.dom.d.ts as missing if fileExists() confirms its presence.

2. Consistent file resolution

   • The order of operations should not cause getCompilerOptionsDiagnostics() to check for lib.dom.d.ts before its resolution is complete.

3. Correct caching behavior

   • If TypeScript is caching file existence checks, it should correctly update its cache before running diagnostics.

4. Immediate correct default library resolution

   • getDefaultLibFileName() should return the correct default library file before diagnostics are run, not after.

Additional information about the issue

No response

[RyanCavanaugh]

I believe this line is wrong:

    lib: ["lib.dom.d.ts"] // should just be "lib.dom"

The provided sample throws unrelated errors; please provide a true runnable sample if you need further help

[s19514tt]

@RyanCavanaugh

Thank you for your response.

I updated lib: ["lib.dom.d.ts"] to lib: ["lib.dom"], but now I encounter a different error:

File '/Users/username/.vscode/extensions/lunasdev.lunas-0.0.1-beta.1/node_modules/typescript/lib/lib.dom' has an unsupported extension. The only supported extensions are '.ts', '.tsx', '.d.ts', '.js', '.jsx', '.cts', '.d.cts', '.cjs', '.mts', '.d.mts', '.mjs'.

The full implementation of the language server can be found here:
server.ts

To reproduce the issue, you can clone my repository. The README contains instructions on how to run the extension and language server. Additionally, .lun files for testing can be found in the test folder of the repository.

Let me know if you need any additional information to help diagnose the issue.

[RyanCavanaugh]

We're not able to provide this level of support. If you have a single runnable standalone script that demonstrates a defect, we can look at that, but this API obviously works for everyone else so there's either something wrong with the way you're calling it, or something very specific about the scenario that needs to be distilled down into an actionable defect

I recommend looking at how other people are using the API: https://github.com/search?q=getDefaultLibFileName&type=code

[s19514tt]

Thank you for your response.

After reviewing my implementation, I realized that I misunderstood the distinction between readFile and getScriptSnapshot in LanguageServiceHost. I had not properly implemented getScriptSnapshot, which led to the issue. Now that I understand the correct usage, I have fixed my implementation, and the problem is resolved.

I appreciate your guidance. My apologies for taking up your time with my own oversight. Thank you for your time.