`@volar/typescript` mistakenly processes VS Code's untitled files as TypeScript code

[mizdra]

I am developing a TypeScript Language Service Plugin that loads CSS files using @volar/typescript.

In VS Code, you can create a new file via "New File...". Immediately after creation, it is not yet saved to the file system, and this state is called "untitled".

@volar/typescript appears unable to handle these untitled files correctly.

How to reproduce

minimum reproduction: https://github.com/mizdra/repro-volar-untitled-non-ts-file

1. Run commands in your terminal

   git clone git@github.com:mizdra/repro-volar-untitled-non-ts-file.git
   cd repro-volar-untitled-non-ts-file
   npm i

2. Open the workspace in VS Code
3. Run "Start extension in VS Code" debug task (F5)
4. Create untitle file by Command+N
5. Type .foo {} in the file
6. Change language mode CSS

2025-08-26.22.42.14.mov

Additional information

• It appears that tsserver is mistakenly processing the code as TypeScript.
  • If you write TypeScript code, no errors will be reported.
  • 
• This issue occurs in both css-modules-kit and Vue (Official).
  • css-modules-kit: Errors are reported in an untitled CSS file in VS Code mizdra/css-modules-kit#237
  • Vue (Official):
    • 
• The languageId not found warning was output to tsserver.log. It might be related to this issue.
  • The warning comes from Volar.js.

  • volar.js/packages/language-core/index.ts

    Line 57 in 762323e

    console.warn(`languageId not found for ${id}`);

  • Full log: tsserver.log

...
Info 112  [22:51:56.697] Loading typescript-plugin-css-modules from /Users/mizdra/src/localhost/gomi/repro-volar-untitled-non-ts-file/packages/vscode (resolved to /Users/mizdra/src/localhost/gomi/repro-volar-untitled-non-ts-file/packages/vscode/node_modules)
Info 113  [22:51:56.697] Plugin validation succeeded
Info 114  [22:51:56.698] Starting updateGraphWorker: Project: /dev/null/inferredProject1*
Err 115   [22:51:56.698] languageId not found for ^/untitled/ts-nul-authority/Untitled-1
...

[mizdra]

I will investigate whether there is a way to resolve this issue.

[mizdra]

I am still investigating, but I share my current thinking.

The root cause of this issue is that the Language Service Plugin cannot determine the file's language (a.k.a. languageId). The only information available to the Language Service Plugin is the file path and which plugin should handle the file. This is provided by the Language Client (such as vscode.typescript-language-features) via the updateOpen request.

As an example, consider the log shown in #286 (comment).

Info 101  [22:51:56.695] request:
    {
      "seq": 10,
      "type": "request",
      "command": "updateOpen",
      "arguments": {
        "changedFiles": [],
        "closedFiles": [],
        "openFiles": [
          {
            "file": "^/untitled/ts-nul-authority/Untitled-1",
            "fileContent": ".foo {}",
            "plugins": [
              "typescript-plugin-css-modules"
            ]
          }
        ]
      }
    }

arguments.openFiles[].file contains the file path, and arguments.openFiles[].plugins contains the plugins that should process the file. However, the file's languageId is unknown. The languageId for ^/untitled/ts-nul-authority/Untitled-1 could be TypeScript or could be CSS.

Not knowing the languageId is a serious problem for the Language Service Plugin. It cannot decide whether to parse the file with the TypeScript parser or the CSS parser. Without the correct parser, it cannot report correct syntax errors.

Therefore, to solve this issue, I think the Language Client needs to send the file's languageId. For example, the updateOpen request could be extended as follows.

{
  "seq": 10,
  "type": "request",
  "command": "updateOpen",
  "arguments": {
    "changedFiles": [],
    "closedFiles": [],
    "openFiles": [
      {
        "file": "^/untitled/ts-nul-authority/Untitled-1",
        "fileContent": ".foo {}",
        "languageId": "css",
        "plugins": [
          "typescript-plugin-css-modules"
        ]
      }
    ]
  }
}

This likely requires changes to VS Code similar to the following.

• mizdra/vscode@main...add-language-id

And modify tsserver so that ScriptInfo can have a languageId.

• mizdra/TypeScript@main...add-language-id

Finally, change @volar/typescript to determine the language from scriptInfo.languageId.

• mizdra/volar.js@master...get-language-id-from-script-info

These changes are a PoC and are not guaranteed to work. I believe this solution is technically possible, but it is a very large change. It would require changes in Volar.js (@volar/typescript), TypeScript (tsserver), and VS Code (vscode.typescript-language-features). In addition, there are Language Clients other than vscode.typescript-language-features, so 3rd-party Language Clients might also need changes.

In my view, this solution is too broad in scope and has low feasibility. If there are absolutely no other options, then it may be acceptable to adopt it, but I would prefer to implement a simpler solution if possible.

[remcohaszing]

I ran into the same problem and got to the same conclusion in mdx-js/mdx-analyzer#493 (comment).

Given that TypeScript 7 will replace the tsserver with LSP, I don’t expect the upstream requirements will be met.

[mizdra]

Thanks for sharing your experience with mdx! It's reassuring to know others have reached the same conclusion.

Given that TypeScript 7 will replace the tsserver with LSP, I don’t expect the upstream requirements will be met.

I agree. With the ongoing work to replace tsserver with LSP, I think it's unlikely this change would be accepted by the TypeScript team right now.

By the way, in LSP, the textDocument/didOpen method serves a role similar to the updateOpen command. And this method sends the languageId.

interface DidOpenTextDocumentParams {
    /**
     * The document that was opened.
     */
    textDocument: TextDocumentItem;
}
interface TextDocumentItem {
    /**
     * The text document's URI.
     */
    uri: DocumentUri;

    /**
     * The text document's language identifier.
     */
    languageId: string;

    /**
     * The version number of this document (it will increase after each
     * change, including undo/redo).
     */
    version: integer;

    /**
     * The content of the opened text document.
     */
    text: string;
}

Once LSP is used in TypeScript 7 and the Language Service Plugin is supported in TypeScript 7, this issue will be automatically resolved.