Add language service API to get the compile and runtime dependencies of a source file

[Dirk Bäumer (dbaeumer)]

This PR adds API to the language service to provide the compile and runtime dependencies of a TS file. This information is useful for a package that works independent of the module system and can be used for an incremental compiler that compiles upwards dependencies.

[Dirk Bäumer (dbaeumer)]

I will look into the failures. I wasn't aware that the test harness implements ILanguageService.

[Dirk Bäumer (dbaeumer)]

Here is how the current dependency info looks like:

{
"fileName": "C:/playground/src/base.dom/dom.ts",
"compileTime": [
"base/objects",
"base/util"
],
"runtime": [
"./internal/nodes",
"base/numbers"
]
}

So the fine name is the full path of the source file. This helps to related the dependency information back to the original source file. The compile and runtime dependencies are basically the external module reference strings. I looked into providing the full path to the resolved ts/d.ts file however this information isn't available for amd dependencies like ///

But I am open to change the format to something that includes the full path to the resolved source file if it is available.

[Mohamed Hegazy (mhegazy)]

initially i thought that compileTime is a subset of runtime, but then looking at the code, that did not turn out to be the case. i think we need better names here. maybe "compileTimeOnly", or "non-js dependencies.."

[Mohamed Hegazy (mhegazy)]

Sorry Dirk Bäumer (@dbaeumer) for the delay. i have a general question, do you really need to know what reference is emitted and what is not? I understand that this is an accurate representation of the compiler behavior, but i wounder if this would allow for significant improvements compared to the complexity added in querying the information (i.e. needing the file to be fully type checked to get this information correctly, where as the other one can be done syntactically, just a simple tree walk).

[Dirk Bäumer (dbaeumer)]

Mohamed Hegazy (@mhegazy) no problem. I was busy with VSCode anyway. I would really like to have the information whether the reference is compile time only or run time. The reason is that we want to use that for packaging. Currently we rely on some JS tools for packaging and these toosl change whether we compile to AMD or CommonJS. The nice thing about TS is that it is module system independent. So a tool that analyses runtime dependencies can be independent of the module system as well. This is even more helpful when SystemJS becomes adopted. It would mean we don't have to change our packaging story when we compile to ES6.

I like the proposal to make the list more expressive. However to not make it to confusing with the names and easier maintainable in the future the list should contain object literal and not strings only. That way we can have only two top level properties for now. The literal would look like this:

enum ImportKind {
Type, // The importing module only references types / symbols from the imported module
Code // The importing module needs code from the imported module
}

interface ImportInformation {
"name": string; // e.g. "internal/numbers",
"kind": ImportKind // e.g. Type
}

Something like
{
"filename": "...",
"amdDependencies": ImportInformation[],
"imports": ImportInformation[]
}

The import kind of amd dependencies would always be Code.

We could also add an additional flag to the getDependencies function to indicate if the import kind should be computed. If not requested then a syntax walk would be sufficient.

I wasn't aware of the work Vladimir Matveev (@vladima) is doing with module resolution. I will definitely have a look at it (I think his work is still on a branch) and adopt the getDependencies feature.

I will also add code to force the type check. Thanks for pointing this out to me.

[Karan Sikka (ksikka)]

What are the next steps here?

[Mohamed Hegazy (mhegazy)]

This has been superseded with the builder work. closing.