Temporary files not beeing removed after tests are completed (Jest, Windows)

[armano2]

Operating System

• Linux
• Windows 7
• Windows 10
• MacOS
• other:

NodeJS Version

• 8.x
• 10.x
• 12.x
• 13.x
• other:

Tmp Version

0.1.0 and master

Expected Behavior

Temporary files should be removed after test is finishes

Experienced Behavior

Temporary files are not removed

---

I'm experiencing this issues within jest tests, this can be reproduced in

• https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/typescript-estree/tests/lib/persistentParse.ts
• https://github.com/conventional-changelog/commitlint

If needed i can prepare small repo project or create test scenario

[armano2]

i did some digging and this seems to be issue with jest isolating tests
process events are not being triggered and cleanup is not triggered

[silkentrance]

I will have a look at this.

[silkentrance]

@armano2 Ah I see. Now, there was a change to the rmdirSync API which expects a second optional parameter. ATM we will pass the next handler to this function, too, which causes node fs rmdirSync to fail.

There is already a bug fix for that. Perhaps you can try out node-tmp/master?

I am currently working on stabilising the solution and getting the event handling stuff right. Hopefully @raszi will then make a new release 😄

Other than that: this should be a duplicate of #209

[silkentrance]

Reopening, seeing that you already tried out master.

[silkentrance]

I just tried this with the latest master and running the tests from your project.

Turns out that the temporary objects are cleaned up as expected.

However, the SIGINT handler will not be called on CTRL-C. But this is a different issue.

Can you please check this again with the latest master?

[silkentrance]

There is a bug in current master on dirSync/removeCallback. (next is not a function.)
The problem lies in the rimrafSync wrapper for removing directories. Will open a new issue for this, see #230.

[silkentrance]

@armano2 is this the issue that the SIGINT handler will not be called?

[armano2]

yes, i did some debugging and it looks like process.on and process.addEventListener is not triggered at all

[silkentrance]

@armano2 thank you.

I just did some debugging and by looking at the jest code, it seems that they actually switched over to worker threads. In the past, they would just import the test suite module and provide it with a more or less empty sandbox context. This lead to the fact that tmp got loaded multiple times, installing its listeners over and over again.

With the workers now in place, the test suite module will be loaded in the context of the so spawned worker thread and tmp will be loaded once per worker thread, no longer installing its listeners multiple times.

In order to test this, I added the import for tmp to jest-cli and put some debug output in the safe listener installer, logging the available listeners. It shows that the process object is different from the worker thread's process.

https://nodejs.org/api/worker_threads.html#worker_threads_class_worker

And ATM I do not see any way of making SIGINT/EXIT handlers work in that scenario as these signals will not be passed to the worker thread.

[silkentrance]

Here is a small diagram on how the process environment looks like and which handlers will be called

main process (standard SIGINT handler is used)
-- worker thread (will be terminated as soon as the main process is interrupted, tmp exit handler will not be called)