Associate companion files with `ProjectService` without Content Mappers
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- angular, go, typescript
- Ambito
- developer-experience, tooling
Direzione di ricerca
Start by tracing ProjectService handling for getDefaultProjectForFile, extraFileExtensions, and Content Mappers. Compare how include globs and companion files are associated with projects, then define how a lightweight registration could avoid content transformation and virtual .ts AST generation. Done means an external HTML template can discover its project on cold start without the fake open workaround.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
🔍 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
-
What do you want to use this for?
Angular language service -
What shortcomings exist with current approaches?
Mentioned above -
What workarounds are you using in the meantime?
attempting to open a ts file with the same name
- Lingua principale
- Go
- Stelle
- 112k
- Fork
- 15.4k
- Merge medio
- 2g 21h
- PR unite (30g)
- 126
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/TypeScript
-
Won't Fix
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
microsoft/TypeScript#65107 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Native API: formatDiagnosticsWithColorAndContext drops related information without a file locationForse già presa @timurzvural l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
microsoft/TypeScript#65087 ·
I maintainer di solito rispondono entro 1 giorno
-
TS7 LSP: documentHighlight returns nothing when the file path contains '@'Forse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. ApertaBug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
microsoft/TypeScript#64758 ·
I maintainer di solito rispondono entro 1 giorno
-
Language server (tsc --lsp) exits with code 1 after `shutdown` and `exit`Forse già presa @rajnish-verma-22172 l’ha presa 13 giorni fa. ApertaBug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
microsoft/TypeScript#64742 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Class names `eval` and `arguments` are not reported as invalid strict mode bindingsForse già presa @dmety l’ha presa 26 giorni fa. ApertaBug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
microsoft/TypeScript#64661 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di microsoft/TypeScript
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
hyperledger/fabric-x-orderer#1409 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
needs-area
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Azure/typespec-azure#5936 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
-
Fix mode unpins a reusable workflow call when the same repository is also used as a step actionAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
github/gh-actions-lock#261 ·
I maintainer di solito rispondono entro 1 giorno