- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 357
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: isaacs/node-lru-cache
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: v7.10.2
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: isaacs/node-lru-cache
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: v7.10.3
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 4 commits
- 12 files changed
- 3 contributors
Commits on Jun 27, 2022
-
Configuration menu - View commit details
-
Copy full SHA for 34f5be6 - Browse repository at this point
Copy the full SHA 34f5be6View commit details -
Update breaking info in changelog entry for v7
Add missing information about breaking change to the function signature of the dispose option.
Configuration menu - View commit details
-
Copy full SHA for 57fee05 - Browse repository at this point
Copy the full SHA 57fee05View commit details
Commits on Jun 29, 2022
-
fix: do not dump() background fetches, track start
If saving a `dump()` to a file or database, and then expecting to load it again at a later time in another cache object with `cache.load()` then two awful things could happen. 1. If a background fetch was in progress, it would dump the `Promise` object in the array. This is _never_ what you want, and leads to errors being thrown when attempting to serialize to JSON. 2. The TTL was being dumped, but the _start_ time was not, meaning that you could dump() an entry with only 1ms left on its 1-hour TTL, but when reloading it into a new cache, it would be assumed valid for a full hour. 3. Dumps did not include stale entries at all, so there was no way for a cache to decide whether to allowStale or not later on. Sometimes, this is preferrable. Now, dump() will always output stale entries (since they can be resolved accurately for staleness later anyway).
Configuration menu - View commit details
-
Copy full SHA for 3b2fb03 - Browse repository at this point
Copy the full SHA 3b2fb03View commit details -
Configuration menu - View commit details
-
Copy full SHA for b9918de - Browse repository at this point
Copy the full SHA b9918deView commit details
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.