It turns out that when you make changes to required modules, you're actually modifying the require cache.
This led to an edge case where if the same module was loaded more than once without invalidating the cache, the resulting block(s) had functions that were already bound, and were bound again by their respective construct's load function, which in turn wrecked havoc as it displaced all the expected function arguments over by however many times the module had been loaded.
The straight forward solution to this is minor in code, but might not be the best: Deep cloning the module when using it as an argument for loadModule, rather than the reference to the require cache given by require().
While I don't know the effect this will have on performance, which is the main worry, I do know that this solution maintains the original purpose of the cache (and so it won't need to be invalidated when loading the same module more than once).
It turns out that when you make changes to required modules, you're actually modifying the require cache.
This led to an edge case where if the same module was loaded more than once without invalidating the cache, the resulting block(s) had functions that were already bound, and were bound again by their respective construct's load function, which in turn wrecked havoc as it displaced all the expected function arguments over by however many times the module had been loaded.
The straight forward solution to this is minor in code, but might not be the best: Deep cloning the module when using it as an argument for loadModule, rather than the reference to the require cache given by
require()
.While I don't know the effect this will have on performance, which is the main worry, I do know that this solution maintains the original purpose of the cache (and so it won't need to be invalidated when loading the same module more than once).