Inside Pylance's Type Server Protocol: contracts, indexing, cache
Pylance has published a specification for a Type Server Protocol, and the public record is thin: a spec exists, clients query a type-analysis service, and type intelligence moves out of the editor. Everything else — transport, framing, method names, versioning, staleness signalling, the error model — is still unanswered. So this short treats the protocol as a contract to interrogate rather than a feature to summarise. It walks through why a request carrying only a path and a position is underdetermined once interpreters and workspace roots enter the picture, why a response needs to name the analysis context that produced it, and why a final/stale/partial signal is the difference between a cosmetic annoyance and a correctness bug. It also draws the line against LSP: hover gives you a typed answer, but nothing in it says the answer changed because a stub package was installed. The code shapes shown in the video are illustrative templates, not reported wire format. Check them against the document before writing a client. Full write-up: https://hackyjs.com/posts/inside-pylances-type-server-protocol-request-contracts-indexing-boundaries-and-cache-semantics