ts-node-dev sometimes uses old versions of files for compilation

[arbieo]

I am seeing ts-node-dev fail to hot reload files sometimes (even though it notices the file changes and tries to restart according to the output). I don't have any steps to repro and I'm seeing this randomly every 2-3 days.

It seems different enough from the other issues i've seen on here to make its own thread.

I will fully explain my workflow for the most recent case as it may shed some light.

the error looked like:

[INFO] 15:58:29 Restarting: /Users/ryan/app_engine/StoryDoodle/src/server/util/redis.ts has been modified
Using ts-node version 8.0.2, typescript version 3.3.3333
[ERROR] 15:58:32 ⨯ Unable to compile TypeScript:
src/server/cache/JSONCache.ts(5,34): error TS2551: Property 'getAsync' does not exist on type 'IPromisifedRedis'. Did you mean 'hmgetAsync'?
src/server/cache/JSONCache.ts(16,17): error TS2339: Property 'setAsync' does not exist on type 'IPromisifedRedis'.

This is a normal and explainable error but it was only possible with an old file of /util/redis.ts because that's the only time I had hmgetAsync type defined. In addition, other files which depend on this file are compiling correctly. (they should fail on that version of the file)

My flow:

1. Make /util/redis.ts with version A (which would not have this error)
2. Make another file that debends on and works with /util/redis.ts
3. Modify /util/redis.ts to version B (which should produce this error)
4. Change my mind and change /util/redis.ts back to version A
5. Compilation is fine.
6. Create a new file that depends on /util/redis.ts
7. Get this error (which could only occur on version B of /util/redis.ts)
8. Try to resolve error by editing files. This causes visible reloads but error still persists
9. Restarting ts-node-dev by killing and re-running compiles properly

my command: ts-node-dev --respawn src/server/index.ts
OS: MAC OSX 10.14
ts-node-dev version: 1.0.0-pre.32

I can do additional debugging the next time this happens. Just let me know what might help.

[arbieo]

Edit from the future: this is almost assuredly incorrect but kept for reference.

After having other things failing concurrently, I suspect this may be OSX hitting the max number of files.

I suspect that ts-node-dev is silently catching/supressing the error somewhere. If you are seeing similar strange behaviour in OSX I would suggest running the following (stolen from elsewhere on the internet):

$ echo kern.maxfiles=65536 | sudo tee -a /etc/sysctl.conf
$ echo kern.maxfilesperproc=65536 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -w kern.maxfiles=65536
$ sudo sysctl -w kern.maxfilesperproc=65536
$ ulimit -n 65536

[wclr]

Maybe something like this possible, if you find a way to reproduce it consistently, please show it.

[rshea0]

Also experiencing this issue. My reproduction steps are basically the same as the issue author.

Here's the simplified version:

1. Create file util.ts with a function accepting a string.
2. Create file test.ts which calls the function in util.ts, but passes in a number instead of a string (which rightfully causes a compilation error).
3. Modify the function in util.ts to accept a number, which should fix the compile error.
4. The compile error persists unless test.ts is modified to have different content. Just saving the file again will cause a recompile, but the error still persists.
5. Restarting ts-node-dev completely fixes the error.

This is extremely annoying to deal with and results in having to restart the compilation quite often, which can take close to a minute.

[saiya]

I think this issue is same as #60 . As I commented in https://github.com/whitecolor/ts-node-dev/issues/60#issuecomment-512212212, there is a non-intuitive (but NOT bug) behavior due to combination of TypeScript nature and incremental compilation.

[Akryum]

I think it should considered as a bug since it prevents the app from starting without killing and restarting the whole process.

[rhyek]

Yes, I totally agree which is why I stopped using ts-node-dev and opted for a combination of tsc-watch (for the first_success and success options it offers) and node-dev and it's been perfect. No issues whatsoever, but the config is not as straightforward. There are a few gotchas. Mainly, --noEmitOnErrors does not work with tsc's --watch option (which tsc-watch uses internally).

https://github.com/microsoft/TypeScript/issues/34823

[Akryum]

Or webpack :D

[wclr]

The compile error persists unless test.ts is modified to have different content. Just saving the file again will cause a recompile, but the error still persists.

I'll try to fix this with reinitializing compilation on compiler's error, not sure how it will affect large codebase, but this is the only way to get rid of this.

[rshea0]

Maybe a potential solution would be to just recompile files with errors (after dumping the cache) instead of restarting the entire compilation?

Restarting the compilation will still likely result in this package being unusable.

[seiyria]

I've been running into this too, except fairly frequently (on windows). It seems like every time I change a function signature or add a new file, I need to restart the process or it throws errors.

[plaa]

I've just started having similar issues constantly, where the Node server is restarted but uses old version of code, without any errors being present. Killing and restarting ts-node-dev takes the new code into use. This didn't happen earlier, I'm unsure what has changed. I think I upgraded Node in between.

I'm able to reproduce the problem with the following steps:

1. Start the server with ts-node-dev
2. Call an API with curl (not strictly necessary, reproduces without this step)
3. Modify the controller to add console.log('HERE')
4. Save the file --> the server restarts
5. Call the API with curl --> 'HERE' does not get printed
6. Modify the controller line to console.log('HERE2')
7. Save the file --> the server restarts
8. Call the API with curl --> 'HERE2' is printed

I've tested this on 1.0.0-pre.50 (I'm unable to test on newer versions due to #208). Running on macOS. Raising the ulimit -n 30000 limit did not help, the suggested sysctl values are already >40000.

I've tried running with ts-node-dev --no-deps --watch 'src' --no-notify ./src/app.ts (which has worked previously) and ts-node-dev ./src/app.ts.

Any ideas?

[wclr]

@plaa make reproducible example repository.

[plaa]

@whitecolor I minimized the repo and finally figured out that if I remove the explicit --watch 'src' option, it starts reloading the files properly. This seems like a clear bug to me.

Example repo with reproduction instructions: https://github.com/plaa/ts-node-dev-watch-bug

[wclr]

@plaa why you are watching the required code that is already watched? This definitely may lead to some problems. --watch option is for watching arbitrary files/files, it is not intended to be used this way.

[plaa]

@whitecolor Configuration was like this when I joined the project. Possibly because there's some configuration / YAML files under src/ to be watched as well.

In any case, I wouldn't expect specifying files to be watched multiple times to cause such erratic behaviour. It should either cause a clear error, or (preferably) just ignore duplicates.

[wclr]

@plaa ok will see how to resolve it.