This actually interferes with node-elm-compiler, which uses temp as well (they share the same state when run from the same process as they would be by webpack).
I was having random race conditions where sporadically the elm-node-compiler would throw exceptions, claiming that a file it was trying to read did not exist. I traced through the code and found that since these calls share the same temp module state, this loader was actually deleting the file out from under it.
There is a line at the top for require('temp').track(). These cleanup calls should be unneeded anyway.
This actually interferes with node-elm-compiler, which uses temp as well (they share the same state when run from the same process as they would be by webpack).
I was having random race conditions where sporadically the elm-node-compiler would throw exceptions, claiming that a file it was trying to read did not exist. I traced through the code and found that since these calls share the same
tempmodule state, this loader was actually deleting the file out from under it.There is a line at the top for
require('temp').track(). These cleanup calls should be unneeded anyway.