From within a node app I would like to do:
var typeScript = require('typescript');
typeScript.compile('...')
I’m looking to implement the compiler into a build system but without access to a public API (typescript.compile, etc) this is impossible.
Here’s a more complete example of what I would like to do, though the below is for LiveScript, not TypeScript, utilitized in a plugin written for the Brunch.io build-system:
LiveScript = require 'LiveScript'
sysPath = require 'path'
module.exports = class LiveScriptCompiler
brunchPlugin: yes
type: 'javascript'
extension: 'ls'
constructor: (@config) ->
null
compile: (data, path, callback) ->
try
result = LiveScript.compile data, bare: yes
catch err
error = err
finally
callback error, result
include: [
(sysPath.join __dirname, '..', 'vendor', 'prelude-browser-0.6.0.js')
]
Curious if anyone found a work-around?
Update
I ended up implementing my own solution to a variety of the problems listed above and elsewhere. Please see https://github.com/damassi/TypeScript-Watcher for more information and usage.
This one is a bit hacky but it will work.
I thought about this very same just yesterday and I was checking their code. If you check bin/typscript.js from their sourcecode (It is a very very large file, with nearly 21k lines of code), you will see it creates TypeScript.TypeScriptCompiler, and then you will find that this DOES expose a way of compiling.
Now, you need an easy way to expose it. To do this, you will have to modify their code, which is why this is hacky. To do this, you could modify typescript.js by adding:
Right at the end of the file.
Then, you can create an index.js file in the root of the module (notice: install the module in a local scope for all of this: “npm install typescript”), which exposes the object.
And ready! Now you can just call it and compile your code using it. You can check how to use the API for compilation in the tsc.js file.
I apologize in advance for the horrible code ahead:
For some reason whoever wrote the code was a real fan of C# and proceeded to go ahead and use methods called WriteLine, Close and Write, which are in fact just wrappers. You could get this of the overhead of having to add this functions, but you would have to modify a lot of code in the module and it isn’t worth it. I think it is best to have a class to extend (or if you are still on JS, inherit the prototype) and let it do that for you, to make it DRY.
Something really nice is that if you want to translate 500 TypeScript files and put them all into a single .js file, you can just call compiler.addUnit(anothercontent, anotherpath); 500 times and then see it all go into a single file 🙂
Focusing on better things: if you check tsc.js code, you will find a batch compiler class. If you want this for a build process, it might be better to use something more robust like it. It provides watching files and more.
Having browsed the code, I think I will just submit a ticket to the development team and ask them to provide a clearer API ¬¬
Note: All file reads in here are done in a synchronous way. This is bad, very bad, in terms of performance. I don’t know exactly what you plan to do, but I couldn’t recommend more that you find a way to make this async if possible.