Feature Request: Throw fatal error if compilation fails

[jvilk]

Currently, if typescript-require encounters errors during compilation but a previous compiled version of the TypeScript file is present, it will use the old one and chug on.

This is undesired behavior for me, as it's easy to miss the compilation errors and think that your changes did not fix an issue.

If this is desired default behavior, could you expose a configuration option that turns this into a fatal error?

Thanks!

[jvilk]

Apparently TypeScript doesn't call process.exit like you expect, which is why your existing exception isn't triggered.

It's simple to replicate this. Just write a malformed TypeScript file, e.g. don't match a curly brace, and try to require it.

[finalclass]

I've added exitOnError flag. Default is true.

Ohhh, we need npm publush now.

[eknkc]

Published!
Also added you in owners list, should be able to publish now.

[jvilk]

This doesn't fix the issue. Here's a simple example.

example.js:

require('typescript-require');
var tsfile = require('./tsfile.ts');
console.log("I'm still running.");

tsfile.ts:

if (false) {}

Run once, and you get the following output, as expected:

$ node example.js
I'm still running.

Now, change tsfile.ts to the following malformed TypeScript:

if (false) {

Run again:

$ node example.js
/Users/jvilk/Code/doppio_lol/doppio/tsfile.ts(2,1): error TS1005: '}' expected.
I'm still running.

After inserting a debug print, TypeScript does call process.exit with code 1, but it does so after typescript-require returns from my require statement:

$ node example.js
/Users/jvilk/Code/doppio_lol/doppio/tsfile.ts(2,1): error TS1005: '}' expected.
I'm still running.
EXIT CALLED WITH CODE 1

I imagine this is the price you pay for trying to emulate a synchronous require call in an inherently asynchronous language; TypeScript's error handler probably runs in a callback somewhere.

[finalclass]

The problem is that when that script is compiled by node synchronous method vm.runInThisContext() the execution goes further but exit callback is called later asynchonously.

Thus in this version of node it's impossible to rely on process.exit, so this code (it's taken from typescript-require index.js file) will never call exit synchronously:

 var proc = merge(merge({}, process), {
    argv: compact(argv),
    exit: function(code) {
      exitCode = code;
    }
  });

So we need a different way of knowing if there ware compilation errors.
I've got already implemented solution which rely on process.stderr. Generaly speaking when tsc calls process.stderr.write method the process exists with status code 1 and prints all the errors.
I know it's very dirty solution because it's relying on console messages but as for now I don't see any other solution on how to know if the script was compiled successfully or not.

I pushed this solution to the branch "process.stderr" please review it.

[jvilk]

I can test this tomorrow... but I found an alternative solution relying on an external package, if you're interested.

execSync does exactly what you want: https://npmjs.org/package/execSync

[finalclass]

Looks very good. I will try it later.

[svallory]

execSync has a big warning right at the top of that page:

WARNING For dev machine shell scripting only. DO NOT USE for production servers

What do you guys think about using typescript-compiler to do the compilation?

[quenio]

Keeping the compiler running on on its own process ensures it will not affect the execution of the program. The memory and performance requirements of the compiler could affect larger programs. That makes me think that it is better to keep the compiler isolated in its own process.

But there might be other benefits in running in in-process, such as faster execution, or better error handling, or even just-in-time compile.

[svallory]

One thing doesn't affect the other. We can use typescript-compiler and still spawn a new process for the compilation. What I don't know is if spawn processes for compilation is really beneficial. Specially because on a large source base this could mean a lot of processes.