Expose TypeScript-specific globbing behavior

[DanielRosenwasser]

Today, TypeScript's globber uses a custom strategy that acts differently from other tools. This is an issue for 3rd party users who need to consume TypeScript's APIs, but need to validate that a file belongs to a compilation. #32564 dives into some of the discussion around this.

This API doesn't have to be the same as matchFiles - but it needs to compose well with the rest of our API.

[weswigham]

@DanielRosenwasser should this be part of a meta-issue along the lines of "tsc.js should be implementable/implemented using only public APIs"? (Since that's what API consumers are essentially trying to do.) So we audit other possible concerns?

[DanielRosenwasser]

Sure, a minimal core of tsc.js at the very least makes sense. Letting API consumers drive these requests seems like a reasonable way of getting there.

[AviVahl]

Happy to see this discussion, although I'm quite sure there's an open issue regarding this API (lost and forgotten by time and indexes). I might have even commented in one.

Anyhow, it's not just about powering tsc-like builds programmatically. I personally wanted to create a language service using a custom host around my own in-memory fs implementation. The only way I got the globbing behavior to match typescript's default node host was to expose this internal API:
https://github.com/wixplosives/file-services/blob/master/packages/typescript/src/typescript-internals.d.ts

Needed it to provide a readDirectory implementation, which is basically a proxy to this function. I needed other internal APIs as well, but this is a good start, heh. :)

[AviVahl]

Better late than never: #13793