Some of the semantic diagnostics use fileName and not relative file name as part of semantic diagnostics and it makes tsbuildinfo unportable

[sheetalkamat]

🔎 Search Terms

semantic diagnostics file name, tsbuildinfo

🕗 Version & Regression Information

• This changed between versions ______ and _______
• This changed in commit or PR _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

No response

💻 Code

// Your code here

Errors like File_0_is_not_a_module use file name directly and that means they will have full paths in buildInfo making it report incorrect path if tsbuildInfo is ported.
Also need to search through code base to see if there are more such cases and use relative file name instead:
In Checker:
error(errorNode, resolutionDiagnostic, moduleReference, resolvedModule.resolvedFileName)
error(errorNode, diag, moduleReference, resolvedModule!.resolvedFileName)
error(errorNode, Diagnostics.Output_file_0_has_not_been_built_from_source_file_1, redirect, resolvedModule.resolvedFileName);
chainDiagnosticMessages( errorInfo, Diagnostics.Could_not_find_a_declaration_file_for_module_0_1_implicitly_has_an_any_type, moduleReference, resolvedFileName, ),

🙁 Actual behavior

File '/b.ts' is not module.

🙂 Expected behavior

File 'relativeToFileReportedIn("/b.ts")' not module.

Additional information about the issue

No response

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Similar Issues

Here are the most similar issues I found

• (68%) microsoft/typescript#25747: Diagnostics should not include absolute paths
• (68%) microsoft/typescript_old#25747: Diagnostics should not include absolute paths
• (68%) microsoft/typescript#37968: Diagnostics still include absolute module paths on macOS
• (68%) microsoft/typescript_old#37968: Diagnostics still include absolute module paths on macOS
• (67%) microsoft/typescript#42769: Stale errors in tsbuildinfo file
• (67%) microsoft/typescript_old#42769: Stale errors in tsbuildinfo file
• (66%) microsoft/typescript#19588: // @ts-check no longer seems to work for js files in implicit project
• (66%) microsoft/typescript_old#19588: // @ts-check no longer seems to work for js files in implicit project
• (66%) microsoft/typescript#52810: Node10Result on resolvedModule issues
• (66%) microsoft/typescript_old#52810: Node10Result on resolvedModule issues
• (65%) microsoft/typescript#32023: Portable .tsbuildinfo
• (65%) microsoft/typescript_old#32023: Portable .tsbuildinfo

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

The .tsbuildinfo file is a local, machine‐specific cache. It contains whatever absolute path the compiler host resolved at build time so that subsequent incremental builds can unambiguously map back to the same physical file. Because the cache is not meant to be moved or checked in, the compiler makes no attempt to rewrite those paths to be relative or portable. Diagnostics that are serialized into the file therefore include the full canonical path by design. Moving the .tsbuildinfo file to another location is unsupported, so the behavior you are seeing is expected and correct.