[API] An invalid DocumentIdentifier fails with a TypeError from path.js rather than a message naming the argument

[knutwannheden]

🔎 Search Terms

DocumentIdentifier, getSourceFile, startsWith, isBundled, api/path.js, API

🕗 Version & Regression Information

• This is the behavior in every 7.x version I tried: 7.0.2 and typescript@next (7.1.0-dev.20260827.1).
• There is no earlier version to compare against; the API is new in 7.0.

💻 Code

DocumentIdentifier is string | { uri: string }. Passing an object with fileName instead — the spelling used by SourceFileMetadata, getSourceFileMetadata(fileName) and SourceFile.fileName — does not report a bad argument:

import { API } from "typescript/unstable/sync";

const api = new API({ cwd: "/proj" });
const project = api.updateSnapshot({ openProjects: ["/proj/tsconfig.json"] }).getProjects()[0];

project.program.getSourceFile({ fileName: "/proj/a.ts" });

🙁 Actual behavior

TypeError: Cannot read properties of undefined (reading 'startsWith')
    at isBundled (node_modules/typescript/dist/api/path.js:353:17)
    at documentURIToFileName (node_modules/typescript/dist/api/path.js:462:9)
    at resolveFileName (node_modules/typescript/dist/api/proto.js:10:12)
    at Program.getSourceFile (node_modules/typescript/dist/api/sync/api.js:440:26)

The stack points into path handling, several frames below the call, and names neither the argument nor the expected shape.

🙂 Expected behavior

A TypeError naming the argument and the accepted shapes, e.g. Expected a string or { uri } for the document, received an object with keys: fileName.

Additional information about the issue

Minor, but it cost real time while porting a tool from the TypeScript 6 API: fileName is the property name used elsewhere in the same API, so reaching for it is a natural mistake, and the resulting error gives no hint that the argument is the problem.

resolveFileName in api/proto.ts looks like the single place a check would cover both getSourceFile and the other DocumentIdentifier entry points.