-
-
Notifications
You must be signed in to change notification settings - Fork 0
Add introspection, metrics, and config validation #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- Add size(), keys(), values(), entries() methods for cache introspection - Add getStats() and resetStats() for tracking hits/misses/evictions/expirations - Add CacheStats type and CacheConfigError class - Add constructor validation for negative maxSize and ttl values - Filter expired entries from all introspection methods for consistency - Add engines and publishConfig fields to package.json - Add 40 new tests covering all new functionality 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
📝 WalkthroughWalkthroughMemoryCache now validates constructor options and exports CacheConfigError and CacheStats; it records runtime stats (hits, misses, evictions, expirations) and adds introspection/management APIs (size, keys, values, entries, has, prune, getStats, resetStats). Tests, docs, and package metadata were updated. Changes
Sequence Diagram(s)(omitted) Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
Pre-merge checks✅ Passed checks (3 passed)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/cache.test.ts (2)
716-725: Duplicate test case detected.This test "should handle zero TTL (no expiration)" at lines 716-725 is identical to the one at lines 705-714. Remove one of the duplicates.
🔎 Suggested fix
- it('should handle zero TTL (no expiration)', () => { - vi.useFakeTimers() - const ttlCache = new MemoryCache<string>({ ttl: 0 }) - - ttlCache.set('key1', 'value1') - vi.advanceTimersByTime(10000) - expect(ttlCache.get('key1')).toBe('value1') - - vi.useRealTimers() - }) -
749-759: Duplicate test case detected.This test "should handle zero max size (no limit)" at lines 749-759 duplicates the test "should handle max size of 0 (no limit)" at lines 737-747. Remove one of the duplicates.
🔎 Suggested fix
- it('should handle zero max size (no limit)', () => { - const sizeCache = new MemoryCache<string>({ maxSize: 0 }) - - for (let i = 0; i < 1000; i++) { - sizeCache.set(`key${i}`, `value${i}`) - } - - for (let i = 0; i < 1000; i++) { - expect(sizeCache.get(`key${i}`)).toBe(`value${i}`) - } - })
🧹 Nitpick comments (4)
src/cache.ts (2)
37-42: CacheConfigError prototype chain may breakinstanceofchecks in some environments.When extending built-in classes like
Errorin TypeScript targeting ES5, the prototype chain can be broken. Consider addingObject.setPrototypeOf(this, CacheConfigError.prototype)after thesuper()call to ensureinstanceofworks correctly in all environments.🔎 Suggested fix
export class CacheConfigError extends Error { constructor(message: string) { super(message) this.name = 'CacheConfigError' + Object.setPrototypeOf(this, CacheConfigError.prototype) } }
342-354:size()does not clean up expired entries.Unlike
get(), thesize()method iterates and counts non-expired entries but doesn't delete the expired ones from the underlying Map. This is consistent withkeys(),values(), andentries(), but means expired entries remain in memory until accessed viaget()orhas().This is acceptable for a lazy-cleanup strategy, but consider documenting this behavior or adding an optional
prune()method for users who want to proactively clean up expired entries.src/cache.test.ts (2)
1105-1115: Expiration test uses real timers - may be flaky in CI.This test uses
setTimeoutwith real timers (20ms delay) to test expiration. While the delay is short, real-timer tests can be flaky under CI load. Consider usingvi.useFakeTimers()for deterministic behavior, consistent with other TTL tests in this file.🔎 Suggested fix using fake timers
it('should exclude expired entries', async () => { + vi.useFakeTimers() const ttlCache = new MemoryCache<string>({ ttl: 10 }) ttlCache.set('key1', 'value1') ttlCache.set('key2', 'value2') expect(ttlCache.size()).toBe(2) - await new Promise((resolve) => setTimeout(resolve, 20)) + vi.advanceTimersByTime(20) expect(ttlCache.size()).toBe(0) + vi.useRealTimers() })
1143-1153: Multiple introspection/stats tests use real timers.Similar to the
size()test, these tests forkeys(),values(),entries(), andgetStats()use real timers withsetTimeout. For consistency and reliability, consider refactoring all of them to usevi.useFakeTimers().Also applies to: 1189-1199, 1241-1254, 1303-1314, 1324-1334
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
package.jsonsrc/cache.test.tssrc/cache.tssrc/index.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/cache.test.ts (1)
src/cache.ts (5)
MemoryCache(85-486)CacheConfigError(37-42)keys(369-378)values(394-409)entries(424-441)
🔇 Additional comments (9)
src/cache.ts (5)
106-117: LGTM! Constructor validation is well-implemented.The validation correctly rejects negative values while accepting zero (which has special semantics for "no limit" / "no expiration"). The use of nullish coalescing (
??) properly handles bothundefinedand explicitnullvalues.
134-159: LGTM! Stats tracking inget()is correctly implemented.The logic properly tracks:
- Misses when entry doesn't exist
- Expirations + misses when entry is expired
- Hits on successful retrieval
The sentinel value handling remains correct after the stats additions.
194-201: Eviction counting may double-count when updating an existing key at capacity.When the cache is at capacity and
set()is called with an existing key, the current logic will evict the oldest entry and incrementevictions, even though technically no net eviction occurred (the key being set already exists). This may skew eviction metrics.Consider whether this behavior is intentional. If you want to only count true evictions (when adding a genuinely new key forces removal of another), you could check if the key already exists:
🔎 Suggested fix
set(key: string, value: T): void { // Remove oldest entry if cache is full (skip if maxSize is 0 or negative) - if (this.maxSize > 0 && this.cache.size >= this.maxSize) { + if (this.maxSize > 0 && this.cache.size >= this.maxSize && !this.cache.has(key)) { const oldestKey = this.cache.keys().next().value if (oldestKey) { this.cache.delete(oldestKey) this.stats.evictions++ } }
458-466: LGTM!getStats()returns a snapshot copy correctly.By constructing a new object with spread properties and calling
this.size(), the returned stats object is a proper snapshot that won't be affected by subsequent cache operations.
480-485: LGTM!resetStats()implementation is correct.All counters are properly reset to zero while the cache contents remain intact.
package.json (1)
47-52: LGTM! Package configuration additions are appropriate.The
enginesfield correctly specifies Node.js 18+ (current LTS baseline), andpublishConfig.access: "public"is required for publishing scoped packages to npm's public registry.src/index.ts (1)
1-2: LGTM! Public API exports are well-organized.The separation of value exports (
CacheConfigError,MemoryCache,cached) from type-only exports (CacheOptions,CacheStats) follows TypeScript best practices and ensures proper tree-shaking.src/cache.test.ts (2)
1035-1063: LGTM! Constructor validation tests are comprehensive.The tests properly verify:
- Negative
maxSizethrowsCacheConfigErrorwith correct message- Negative
ttlthrowsCacheConfigErrorwith correct message- Zero values are accepted (boundary condition)
1384-1412: LGTM! Combined statistics scenario provides excellent integration coverage.This test verifies the complete stats workflow including hits, misses, evictions, and size after mixed operations, providing confidence in the stats tracking integration.
Replace setTimeout with vi.useFakeTimers() and vi.advanceTimersByTime() in the 5 introspection expiration tests to prevent flaky CI behavior. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/cache.test.ts (2)
716-725: Remove duplicate test.This test is an exact duplicate of the test at lines 705-714 (same name and implementation). Remove this duplication to avoid redundancy and reduce maintenance burden.
🔎 Proposed fix
- - it('should handle zero TTL (no expiration)', () => { - vi.useFakeTimers() - const ttlCache = new MemoryCache<string>({ ttl: 0 }) - - ttlCache.set('key1', 'value1') - vi.advanceTimersByTime(10000) - expect(ttlCache.get('key1')).toBe('value1') - - vi.useRealTimers() - })
749-759: Remove duplicate test.This test is an exact duplicate of the test at lines 737-747. Both tests verify the same behavior (zero maxSize means no limit) with identical implementation. Remove this duplication.
🔎 Proposed fix
- - it('should handle zero max size (no limit)', () => { - const sizeCache = new MemoryCache<string>({ maxSize: 0 }) - - for (let i = 0; i < 1000; i++) { - sizeCache.set(`key${i}`, `value${i}`) - } - - for (let i = 0; i < 1000; i++) { - expect(sizeCache.get(`key${i}`)).toBe(`value${i}`) - } - })
🧹 Nitpick comments (1)
src/cache.test.ts (1)
1311-1322: Consider using fake timers for consistency and reliability.This test uses real timers (
setTimeout) to verify expiration tracking. The PR objectives mention that tests were changed to use fake timers to "ensure deterministic behavior and reduce CI flakiness." For consistency with other expiration tests and to avoid potential CI flakiness, consider using fake timers here as well.🔎 Proposed refactor using fake timers
it('should track expirations', async () => { + vi.useFakeTimers() - const shortTtlCache = new MemoryCache<string>({ ttl: 10 }) + const shortTtlCache = new MemoryCache<string>({ ttl: 100 }) shortTtlCache.set('key', 'value') - await new Promise((resolve) => setTimeout(resolve, 20)) + vi.advanceTimersByTime(101) shortTtlCache.get('key') // triggers expiration const stats = shortTtlCache.getStats() expect(stats.expirations).toBe(1) expect(stats.misses).toBe(1) // expiration also counts as miss + + vi.useRealTimers() })
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/cache.test.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/cache.test.ts (1)
src/cache.ts (5)
MemoryCache(85-486)CacheConfigError(37-42)keys(369-378)values(394-409)entries(424-441)
🔇 Additional comments (4)
src/cache.test.ts (4)
2-2: LGTM!The import of
CacheConfigErroris correct and aligns with the new constructor validation tests.
1035-1064: LGTM!The constructor validation tests comprehensively verify that:
- Negative
maxSizeandttlthrowCacheConfigErrorwith appropriate error messages- Zero values for both options are accepted
This aligns well with the constructor implementation.
1065-1264: LGTM!The introspection method tests are comprehensive and well-structured:
- Cover all new methods:
size(),keys(),values(),entries()- Test empty cache, additions, overwrites, deletions, and clears
- Correctly use fake timers for TTL expiration tests (aligns with PR objectives to reduce CI flakiness)
- Handle special values like
undefinedandnullappropriately
1269-1310: LGTM!The statistics tests comprehensively verify:
- Initial stats are all zeros
- Tracking of hits, misses, evictions, and expirations
getStats()returns current size and excludes expired entriesgetStats()returns a copy (not a reference)resetStats()resets counters without affecting cache size- Combined scenarios track all stats correctly
The tests are well-structured and thorough.
Also applies to: 1323-1423
- Add Object.setPrototypeOf in CacheConfigError for proper instanceof in ES5 - Add prune() method for proactive expired entry cleanup - Refactor size(), keys(), values(), entries() to use eager cleanup via prune() - Add 6 tests for prune() method 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
src/cache.test.ts (2)
716-725: Remove duplicate test.This test "should handle zero TTL (no expiration)" is an exact duplicate of the test at lines 705-714.
🔎 Proposed fix
- - it('should handle zero TTL (no expiration)', () => { - vi.useFakeTimers() - const ttlCache = new MemoryCache<string>({ ttl: 0 }) - - ttlCache.set('key1', 'value1') - vi.advanceTimersByTime(10000) - expect(ttlCache.get('key1')).toBe('value1') - - vi.useRealTimers() - })
749-759: Remove duplicate test.This test "should handle zero max size (no limit)" is an exact duplicate of the test at lines 737-747.
🔎 Proposed fix
- - it('should handle zero max size (no limit)', () => { - const sizeCache = new MemoryCache<string>({ maxSize: 0 }) - - for (let i = 0; i < 1000; i++) { - sizeCache.set(`key${i}`, `value${i}`) - } - - for (let i = 0; i < 1000; i++) { - expect(sizeCache.get(`key${i}`)).toBe(`value${i}`) - } - })
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/cache.test.tssrc/cache.ts
🧰 Additional context used
🧬 Code graph analysis (1)
src/cache.test.ts (1)
src/cache.ts (5)
MemoryCache(86-505)CacheConfigError(37-43)keys(363-366)values(383-396)entries(412-427)
README.md: - Add Cache Statistics and Introspection to features list - Add 7 new methods to API Reference table - Add Cache Statistics example section docs/src/routes/docs/api/memory-cache/+page.svx: - Add constructor validation section with CacheConfigError - Document introspection methods: size(), keys(), values(), entries() - Document statistics methods: getStats(), resetStats(), prune() - Document types: CacheStats, CacheConfigError 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
- Remove duplicate 'should handle zero TTL (no expiration)' test - Remove duplicate 'should handle zero max size (no limit)' test 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
- Convert 'should track expirations' test to use vi.useFakeTimers() - Convert 'should respect TTL' decorator test to use vi.useFakeTimers() 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
docs/src/routes/docs/api/memory-cache/+page.svx (2)
333-339: Consider removing duplicate CacheStats definition.The
CacheStatstype is documented twice: once inline in the Statistics section (lines 333-339) and again in the Types section (lines 402-408). While not incorrect, this duplication could lead to maintenance issues if the type evolves.Consider either:
- Keeping only the Types section definition and referencing it from Statistics
- Adding a comment like "See Types for details" in the inline version
Also applies to: 402-408
418-420: Consider clarifying the CacheConfigError name property documentation.The syntax
name: 'CacheConfigError'(line 419) appears to show a literal type, which may be confusing in documentation context. Consider rephrasing to make it clearer that this is a runtime property value:class CacheConfigError extends Error { // The name property is set to 'CacheConfigError' }Or simply:
class CacheConfigError extends Error { readonly name = 'CacheConfigError' }
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
README.mddocs/src/lib/sitemap-manifest.jsondocs/src/routes/docs/api/memory-cache/+page.svx
✅ Files skipped from review due to trivial changes (1)
- README.md
🔇 Additional comments (4)
docs/src/lib/sitemap-manifest.json (1)
2-6: LGTM! Sitemap timestamps updated appropriately.The timestamp updates reflect the documentation changes introduced in this PR for the new introspection, metrics, and validation features.
docs/src/routes/docs/api/memory-cache/+page.svx (3)
44-58: LGTM! Clear validation documentation.The validation section properly documents the error-handling behavior with a clear try-catch example using
instanceofto check forCacheConfigError.
372-393: LGTM! Clear documentation of the prune() method.The documentation clearly explains the difference between lazy cleanup (on access) and proactive cleanup (via prune), making the method's purpose and use case evident.
287-287: The type signatures in the documentation are correct and match the implementation.The return types
(T | undefined)[]and[string, T | undefined][]are intentional because the cache implementation deliberately supports cachingundefinedandnullvalues using sentinel symbols (CACHED_UNDEFINEDandCACHED_NULL). When these sentinel values are stored viaset(), thevalues()andentries()methods convert them back to actualundefinedornullwhen returning, making the| undefinedportion of the type signature accurate.The example showing
['value1', 'value2']is simply the case where noundefinedvalues have been cached—the type signature still correctly reflects that the return type can includeundefinedwhen applicable.Likely an incorrect or invalid review comment.
Add pnpm.overrides to upgrade cookie to >=0.7.0 (fixes CVE in @sveltejs/kit) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
- Remove duplicate CacheStats definition, reference Types section instead - Clarify CacheConfigError name property syntax 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Fix all issues with AI Agents 🤖
In @docs/src/routes/docs/api/memory-cache/+page.svx:
- Line 246: Replace the ambiguous phrase "Automatically prunes expired entries"
used in the introspection method docs with a clear read-only wording such as
"Excludes expired entries from results" or "Filters out expired entries"
wherever it appears in the memory-cache introspection docs (the descriptions for
size/count-like and entries/keys/values methods), so users understand these
methods do not mutate the cache; keep the separate mutating prune() method
documentation (documented later) unchanged and ensure all occurrences called out
in the review are updated consistently.
🧹 Nitpick comments (1)
docs/src/routes/docs/api/memory-cache/+page.svx (1)
401-411: Consider showing CacheConfigError as an interface or exported class.The current syntax shows internal implementation details (
readonly name = 'CacheConfigError'). For API documentation, consider presenting it as:export class CacheConfigError extends Error { name: 'CacheConfigError' }This makes it clearer that users import and check against this exported class, without exposing implementation details.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/src/routes/docs/api/memory-cache/+page.svx
🔇 Additional comments (2)
docs/src/routes/docs/api/memory-cache/+page.svx (2)
44-58: LGTM! Clear validation documentation.The validation section clearly documents the error handling behavior with a practical example showing proper use of
CacheConfigError.
362-383: The lazy cleanup behavior described in the documentation is accurate. Accessing an expired entry viaget()does trigger cleanup—the implementation actively removes the expired entry from the cache structure (viacache.delete()) and increments the expirations counter, rather than merely filtering results. Theprune()documentation correctly distinguishes this as proactive cleanup for cases where lazy cleanup isn't desired.
Update size/keys/values/entries docs to explicitly state they run prune() before returning results, with links to the prune method documentation. Also adds type annotation and JSDoc to sitemap server file. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
Fix all issues with AI Agents 🤖
In @docs/src/routes/docs/api/memory-cache/+page.svx:
- Around line 242-318: The introspection docs for size(), keys(), values(), and
entries() are ambiguous about pruning; update each method description to state
that the method "Automatically prunes expired entries before returning results"
or "Internally calls prune() to remove expired entries before returning results"
so it clearly conveys that prune() is invoked internally; change the phrasing in
the size(), keys(), values(), and entries() sections to one of those clear
statements and keep the existing examples and return signatures intact,
referencing prune() and the method names (size, keys, values, entries) so
readers understand the behavior.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
docs/package.jsondocs/src/routes/docs/api/memory-cache/+page.svxdocs/src/routes/sitemap.xml/+server.tspackage.json
🚧 Files skipped from review as they are similar to previous changes (1)
- package.json
🧰 Additional context used
🧬 Code graph analysis (1)
docs/src/routes/sitemap.xml/+server.ts (1)
docs/scripts/generate-sitemap-manifest.mjs (1)
manifest(126-126)
🔇 Additional comments (6)
docs/src/routes/sitemap.xml/+server.ts (2)
2-2: LGTM! Improved type safety.The import rename and explicit type annotation improve code clarity and provide better IDE support. The
Record<string, string>type accurately represents the manifest structure (route paths mapped to date strings), and the inline comment clearly explains the purpose.Also applies to: 5-6
13-19: LGTM! Clear documentation.The JSDoc comment accurately describes the
toPathfunction's behavior and follows standard documentation conventions. This improves code maintainability and provides helpful context for future developers.docs/package.json (1)
30-30: All updated dependency versions verified as valid.The dependency updates are legitimate:
@sveltejs/[email protected],@typescript-eslint/[email protected],@typescript-eslint/[email protected], and[email protected]all exist on npm. The TypeScript ESLint packages are properly synchronized, and no security issues were detected. These are routine devDependency maintenance updates.docs/src/routes/docs/api/memory-cache/+page.svx (3)
44-58: Clear documentation of constructor validation.The validation section properly documents the CacheConfigError behavior with a clear example showing how to handle invalid configuration. The try-catch pattern and error checking are well-illustrated.
320-383: Well-documented statistics and pruning API.The statistics section clearly documents all three methods with comprehensive examples. The distinction that
resetStats()"Does not affect cached data" is a helpful clarification, and theprune()method is properly described as the explicit cleanup mechanism for expired entries.
385-416: Comprehensive type documentation.The types section provides clear definitions for both
CacheStatsandCacheConfigError. The documentation properly cross-references the validation conditions (negativemaxSizeorttl) and includes helpful import examples.
Update size/keys/values/entries docs to explicitly state they internally call prune() to remove expired entries before returning results. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (1)
docs/src/routes/docs/api/memory-cache/+page.svx (1)
320-343: Consider clarifying thatsizein stats reflects non-expired entries.The
getStats()documentation is clear, but for consistency with the introspection methods documentation (which explicitly mentions expired entries are removed), consider adding a note that thesizefield reflects non-expired entries only.🔎 Suggested clarification
Add a note after line 330 or in the example explanation:
**Returns:** Object containing cache statistics (see [CacheStats](#cachestats) type) + +**Note:** The `size` field reflects the count of non-expired entries, as expired entries are automatically pruned.Alternatively, add this to the CacheStats type documentation at lines 387-399.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/src/routes/docs/api/memory-cache/+page.svx
🔇 Additional comments (3)
docs/src/routes/docs/api/memory-cache/+page.svx (3)
44-58: LGTM! Clear validation documentation.The validation section clearly documents the error-throwing behavior with a practical example. The
instanceofcheck is the correct pattern for error handling.
242-318: Introspection documentation is now clearer.The updated wording "Internally calls
prune()to remove expired entries before..." effectively addresses the past review concerns about ambiguity. This phrasing clearly conveys that:
- The pruning happens automatically as part of the method call
- Users don't need to manually call prune() first
- Expired entries are removed from the cache before results are returned
The consistent documentation pattern across all four methods (size, keys, values, entries) helps users understand the behavior.
385-416: LGTM! Types are well-documented.The type definitions are clear and complete:
CacheStatsaccurately lists all tracked metricsCacheConfigErrorclearly documents when it's thrown (negative maxSize or ttl)- The error class definition shows the proper inheritance and name property
Summary
size(),keys(),values(),entries()methods for cache introspectiongetStats()andresetStats()for tracking hits/misses/evictions/expirationsCacheStatstype andCacheConfigErrorclass for better developer experiencemaxSizeorttl)get()/has()enginesandpublishConfigfields to package.jsonTest plan
🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes / Validation
Documentation
Chores
Tests
✏️ Tip: You can customize this high-level summary in your review settings.