Description
To enable meteor developers the use of TypeScript in meteor packages and application code, we are currently working on a compiler plugin that needs to integrate into the meteor specific build system.
_note: the 9th most stared Github repo, before ruby/rails, is the meteor js framework
The problem is that the meteor build system instruments a caching and bundling system that obfuscates access to the file system, which seems to challenge the fs and typescript api coupling.
I. e. during meteor build an [1]array of input file objects that each incl. filename, -path, -hash and -content (data) properties is passed to the compile plugin (here typescript) and expected to be returned as [2]transpiled content via a method handler. Without touching the file-system.
Analog to the "A minimal compiler" API example, it seems to be easy to cover [2] by providing a custom compileHandler: ts.WriteFileCallback
into program.emit(undefined, compileHandler)
to pass the transpiled content back upstream.
export function compile(fileNames: string[], options: ts.CompilerOptions): void {
var program = ts.createProgram(fileNames, options);
var emitResult = program.emit();
//...
But can [1] lead to a full Program
instance without providing fs-access just with "virtual" file paths and file contents?
- It would be convenient to have
ts.createProgram
accept file objects that encapsulate file properties such as content etc. to make the compiler file-system agnostic.
Any given advice to prevent redundant disk access while maintaining source maps, incremental builds and diagnostics inside this build chain?