Uncaught errors when target JS file exists and MAP file doesn't exist

[1999]

Error: ENOENT: no such file or directory, open '/var/folders/44/40437cm97md6b8zn0rs8fy5mhhh0hc/T/ts-node-17b38112533313593deb1e0606cb377b3ed838e2087adea7b5cc097b01b8f44a/639d71863f6c7f45f1df4ada0591cabc1ce103b9a28c16ddb08fbb10f4c3646f/8421e53249316d93f9faaf989bf056d61457a056cb0531fa3bd39aa8c9198bed.js.map'

This is a problem I faced today and spent couple of hours working on. it looks like source map file generation failed for some reason for me. After that my ts-node process was working fine until error occured. It was trying to build the stack trace from source maps: the cache.sourceMaps contained information about the file but the map file didn't exist in the file system: https://github.com/TypeStrong/ts-node/blob/master/src/index.ts#L172

The problem is that fileExists only checks the target file: https://github.com/TypeStrong/ts-node/blob/master/src/index.ts#L485

[blakeembrey]

Thanks for the report! I think I'm going to bundle this and #355 into a more permanent fix. Not entirely sure how, but checking two files before every load may get a little expensive so it might be worth looking into trying to use a single cache file loaded on start-up and periodically writing it back to the filesystem. What do you think?

[blakeembrey]

It'd also be even easier to combine the source map and JavaScript file into a single file here instead of having two files output - this would be a better temporary solution until the idea above is implemented.

[1999]

use a single cache file loaded on start-up

Totally agree. I was a bit shocked when I discovered that ts-node is performing synchronous i/o operations (fileExists) for errors each time. If you need some help here, I can join.

source map and JavaScript file into a single file

Yep, this was a easiest solution I came up with after some time. I just thought it would be useful for ts-node if I report it here.

[blakeembrey]

@1999 I did #368, which merges the two files together. On the single file cache - I'd be happy to do that in the next major release. I haven't thought about how it might interact with multiple processes and such, but just reading it at startup and writing on each batched compilation feels reasonably suitable.