API: parseConfigHostFromCompilerHost misbehaves if host.readDirectory is not implemented

[ajafff]

TypeScript Version: 3.1.0-dev.20180830

Search Terms:

Code

src/tsconfig.json

{
  "compilerOptions": {"composite": true},
  "include": ["."]
}

test/tsconfig.json

{
  "references": [{"path": "../src"}]
}

Calling ts.createProgram on test/tsconfig.json with a custom CompilerHost that doesn't implement the optional method readDirectory.

Expected behavior:

Some kind of error or warning when passing projectReferences to ts.createProgram without implementing CompilerHost#readDirectory. I wondered what is wrong and only found this implementation detail by chance.

Actual behavior:

The ResolvedProjectReference returned from program.getProjectReferences() has an empty fileNames array.

https://github.com/Microsoft/TypeScript/blob/828279b611978e081eba0de1a1c126e415e306dd/src/compiler/program.ts#L2816

[RyanCavanaugh]

The problem here isn't references, it's include - you can't have a functional include setup without readDirectory. But some people are using this API to just examine the tsconfig files for other stuff (e.g. settings) without enumerating the file system and they have a legitimate use case for not implementing readDirectory.

I think this just falls under "the host API has to be fully implemented according to what you intend to do"

[ajafff]

some people are using this API to just examine the tsconfig files for other stuff (e.g. settings) without enumerating the file system and they have a legitimate use case for not implementing readDirectory.

I disagree. This issue is about ts.createProgram which is not just called to examine tsconfig files. In addition you have to explicitly use the new signature of that function which takes an object parameter and explicitly add the projectReferences property in order to actually process referenced tsconfig files. In that case it should warn if readDirectory is not implemented

[RyanCavanaugh]

At that point it's too late - createProgram can't tell that there was an include pattern. Getting an options-bag call to createProgram is still valid even if readDirectory isn't implemented.

[ajafff]

At that point it's too late - createProgram can't tell that there was an include pattern.

It seems like we are talking past each other. So here is a more detailed description:

I call createProgram with the data of the entry tsconfig.json. Parsing that file is my responsibility and I need to implement ParseConfigHost#readDirectory because it's required by the interface.

I use the new signature of createProgram and explicitly add projectReferences to the options object. That means I want createProgram to resolve all project references. To do that it creates a ParseConfigFileHost from the CompilerHost I provided. *1
Now it processes all projectReferences and parses the config files using the newly created ParseConfigFileHost. If there is a referenced tsconfig.json with include, ParseConfigFileHost#readDirectory is called, which in turn tries to call CompilerHost#readDirectory. If that isn't implemented (because it's optional) it simply falls back to an empty list of files. *2

After creating the Program I want to inspect program.getProjectReferences()![0]!.commandLine.fileNames. I'm surprised the list is empty. The referenced project contains files, which are specified in include. And I didn't see an error telling me I forgot to implement CompilerHost#readDirectory to correctly use the project references feature.

I'm proposing throwing an error at position *1 or *2 in case host.readDirectory is not implemented and projectReferences is a non-empty array.

[RyanCavanaugh]

I see; I hadn't considered the upstream config files. Thanks for being patient.

An assert here would indeed be useful, probably at *2