Closed dominicbarnes closed 9 years ago
arg haha, this is a good intermediary step. I think the caching has to do with a race condition because I can't reproduce it all the time.
I was looking into it this weekend along with how browserify-incremental
does it (spoiler: it doesn't).
Yeah, I've just accepted it as a necessary evil for now too.
I'm sure we can improve upon the entire caching model, perhaps even using a more sophisticated system under the hood. (maybe a proper database like leveldb or something?)
If we can come up with a simplified, reproducible case where the caching layer fails, I think that would be a good start. I haven't even been able to do that. I just know it fails a lot
My initial guess is that the mapping
is read and not updated after writes by multiple instances of duo. we have atomic writes, but we let consumers read the mapping whenevs
This adds
Duo#cleanCache()
to the API andduo clean-cache
to the CLI. This particular "cache clean" destroyscomponents/duo.json
, and the CLI also calls uponPackage.cleanCache()
to round out all of duo's current caching implements.This will address #437