TSC test runners: how to write a test that has both reference chasing and language service?

Topics: Code Checkins
Sep 13, 2013 at 9:30 AM
Looking at the TypeScript sources, I see tests that chase dependencies but only compile, and I see tests that involve the language services but do not chase (external) dependencies.

How would I set up a test case that loads src/compiler/tsc.ts and all its dependencies, then lets me work with the language services (as in the fourslash tests)?

I would like to check the following situation:
  • load tsc&dependencies
  • getAllDiagnostics
  • edit file src/compiler/core/require.ts (just add an empty line or something, don't save)
  • getAllDiagnostics
In my own language service client, the last step suddenly claims an error in src/compiler/io.ts. I think what happens is that type checking compares the type for the same symbol (IO) in different inference states (any vs IIO), and complains about them being different instead of using only the more specific type. But I don't know why that happens.
Developer
Sep 13, 2013 at 9:23 PM
If you look in the constructor for the TestState class in src\harness\fourslash.ts you can see where we do resolve dependencies with language service related tests. The fourslash tests are the closest test sources to the scenario you're describing.
Sep 14, 2013 at 9:32 AM
Yes, but the fourslash tests tend to resolve the dependencies from inline sources, via //@Filename:, which is impractical for the whole of tsc. My attempts to import a real, external module, or to reference include tsc, have not yet succeeded, so a working example of doing this would be helpful.

Meanwhile, the issue is caused by a conflict between typeScript.ts, which has declare var IO: any, and io.ts, which has a global var IO (inferred type IIO). On first load, this conflict doesn't cause a problem, but when getting semantic diagnostics for io.ts (after updating require.ts), the complaint (TypeScript.DiagnosticCode.Subsequent_variable_declarations_must_have_the_same_type_Variable_0_must_be_of_type_1_but_here_has_type_2) is raised in PullTypeResolver.prototype.validateVariableDeclarationGroups. Removing the declaration of IO in typescript.ts avoids the complaint.
Sep 16, 2013 at 9:24 AM
clausreinke wrote:
Yes, but the fourslash tests tend to resolve the dependencies from inline sources, via //@Filename:, which is impractical for the whole of tsc. My attempts to import a real, external module, or to reference include tsc, have not yet succeeded, so a working example of doing this would be helpful.
The TestState constructor instantiates a HarnessCompiler and calls HarnessCompiler.resolve; that delegates to TypeScript.ReferenceResolver.resolve(this.inputFiles, this, this.compiler.settings) where the second parameter is the host, in this case an instance of HarnessCompiler; so when resolution checks fileExists, it only checks for already loaded files, which fails for external imports/references, so they never get loaded.