3
Vote

modularize compiler and language services

description

Currently, the only way to reuse parts of the typescript project is by using 'reference path' includes. In fact, the whole project source ignores the language features of external modules, import and export (possibly because the source predates the availability of these features?).

This prevents use of a module system in client code and leads to ridiculous hacks like the one used to get 'typescriptServices.js' into 'harness.ts'. Another example are editor and IDE clients of the language services.

For my own tool [discussion:405174], I have to precompile my code, putting generated .js into the repo, because I cannot just import the services from the npm module (others have the same issue: http://typescript.codeplex.com/workitem/97).

blocking: workitem/97
blocked by: more complete support for ES6 modules (currently not before 0.9.x on the roadmap.. http://typescript.codeplex.com/wikipage?title=Roadmap)

comments

clausreinke wrote Dec 1, 2012 at 8:55 PM

Collecting examples that could be more modular:

'src/harness/harness.ts':
vm.runInThisContext(typescriptServiceFile, 'typescriptServices.js');
'src/compiler/tsc.ts':
// Start the batch compilation using the current hosts IO
var batch = new BatchCompiler(IO);
batch.batchCompile();

The first hack should not be needed, and represents the need proper modularisation.
The latter direct code prevents import/include of 'tsc.ts', which has code for instantiating dependency resolution.