API: Subsequent calls to cruise will return same result even when file changed about dependency-cruiser HOT 6 CLOSED

So you are using the API, right? There are some global caches in there that are never cleared unless you start a new process.
AFAICT it'd be a fairly large refactoring correctly clear those caches.

from dependency-cruiser.

You are correct I am using the API. It seems to be that way. Any workaround to force it to not use the cache you mentioned? Perhaps one of the keys in options?

Restarting the process again will be a solution yes but it defeats the purpose of the optimization tool i am building. Any suggestion is appreciated.

Thanks

from dependency-cruiser.

Hi @wongjasont interesting use case :-)

It's as @ajafff says - dependency-cruiser caches a lot to be performant. That said, the situation is not as dire as implied above :-) - dependency-cruiser has more situations which need cache busting (unit & integration tests for instance).

• Caching is implemented with memoization over the function that does the actual work. In a most cases the unmemoized function is available already - just not exposed in the API. It'll be some work to expose that in the API, but I expect it to be straightforward.
• The (webpack enhanced-resolve) has its own caching mechanism - but I've implemented a bustTheCache resolve option to be able to do exactly that.

(OTOH implementing a cache invalidation mechanism that only invalidates that which is strictly necessary will indeed be harder...)

from dependency-cruiser.

@wongjasont version [email protected] should solve this issue - could you give it a spin?

(I've made a first implementation of cache invalidation that should work in your use case - it was easier to cook than expected 😍 @ lodash).

from dependency-cruiser.

@sverweij Tried it and this works perfectly! Really appreciate the quick turnaround 👍

from dependency-cruiser.

Hi @wongjasont - I've published 4.18.0 as a regular version on npm. It contains the resolution for this issue you tested earlier. A.c.t. the version you tested I found I missed a a cache clean call to the (webpack enhanced-resolve cached filesystem) resolver. 4.18.0 contains the fix for that as well (details in PR #129).

from dependency-cruiser.