Associate companion files with `ProjectService` without Content Mappers

[atscott]

🔍 Search Terms

extraFileExtensions
ScriptKind.Unknown
getDefaultProjectForFile
companion files
cold start project
openProjects

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Something like content mappers for registering extra extensions as included in the project but without the requirement of actually doing content mapping

📃 Motivating Example

We're currently prototyping the new Angular Language Service against TS-Go (tsgo --lsp with the API session pipe). In our setup, our extension manages a separate language server to handle Angular-specific template features, and uses TS-Go as the backend semantic and type-checking engine.

Because we manage our own compiler instance per tsconfig.json, we need to know which project owns a file when it's opened. We're running into a cold-start discovery problem when a user opens an external template first (e.g. app.component.html): getDefaultProjectForFile returns nothing because TS doesn't recognize .html as belonging to any configured project. Since Angular hasn't compiled yet, we don't know the TS ↔ HTML association either, so we don't know which tsconfig to load.

To work around this today, we do a "fake open dance" where we guess a sibling app.component.ts file, send a synthetic didOpen to TS-Go just to spin up the project and discover the tsconfig path, and then boot our compiler.

Content Mappers don't really fit here because they require transforming foreign files into virtual .ts ASTs and generating .ts output. For Angular, HTML files are external companion templates—our template type-checking code is generated out-of-band in separate .ngtypecheck.ts files. Forcing a Content Mapper onto .html files just introduces unwanted .ts AST generation and emit overhead.

Previously, extraFileExtensions with ScriptKind.Unknown kept projects active when matched by include globs. Since non-TS extensions in include globs are more standard now with content mappers, we're fine requiring .html in include. A lightweight extension registration (or a no-transform companion mode that lets include globs associate .html with ProjectService without generating virtual .ts ASTs) would eliminate the cold-start issue and the fake open workaround.

💻 Use Cases

1. What do you want to use this for?
   Angular language service

2. What shortcomings exist with current approaches?
   Mentioned above

3. What workarounds are you using in the meantime?
   attempting to open a ts file with the same name