This is how I currently use them together:
- Open three terminals
tsc --out client/main.js client/main.ts --watchin the first.
tsc --out server/main.js server/main.ts --watchin the second.
meteor runin the third.
To start working on your own project, fork
meteor-typescript-seed and follow the instructions.
My first attempt was to use the Meteor package meteor-typescript-compiler. However, it turns out that it still uses Typescript
1.0 and is slow in compilation.
I tried to fix that, taking inspiration from the grunt-ts’s monkey patching.
Also, I forked meteor-typescript-compiler so that I could cut out the intermediate packages and do the Typescript mangling in the meteor package itself. Ironically, I struggled with some issues with Meteor’s erroneous error reporting.
It turns out that the
vm.runInThisContext trick to eval
grunt-ts uses, does not work while working from inside Meteor because
require is not defined in Meteor’s context. Hence, the magic/mangling needs to happen in a separate
Curioser and curioser.
However, it turned out that Meteor’s build system would make it very difficult for types in one file to depend on types defined in another file. If I changed a file on which several others files depended for type-checking, the decendants will not be recompiled, thanks to caching employed by
meteor-typescript-compiler. The alternate was to compile each file separately each time anything changed. So, that was a no-go, in the end.
Also, I discovered, thanks to Tomas that Typescript will gladly do the task of watching dependent files which were referenced using
<reference path="./file/path.ts" /> syntax. That was the time I decided to take this path.
I will look into integrating Typescript in the build system again after the Typescript team releases a stable API for their compiler.