lru-queue review
lru-queue 0.1.0 tracks the least recently used order of plain string IDs and nothing else. Call `hit(id)` when an external cache reads or writes a value; once the configured limit is crossed, the call returns the ID that your code must evict from its own store. `delete(id)` removes recency state and `clear()` empties the queue. Our install pulled 10 packages because the tiny queue depends on `es5-ext`. The project was extracted from memoizee and still fits that internal bookkeeping job, but it is not a cache, has no value lookup, and cannot report its contents.
lru-queue 0.1.0 took 2.1 seconds and 10 installed packages for a three-method string-ID queue in our sandbox, while storing no cached values. Keep it only where old memoizee-style plumbing already expects its eviction-ID contract; start new cache code with `lru-cache` or `quick-lru`.
We installed it
| Install | ✓ · 2.1s | 10 packages on disk · 4 MB |
| Import | ✓ | ESM import works · require() works · CommonJS package |
| Browser | 0.7 KB | gzipped (1.5 KB minified), bundled with esbuild |
| Types | — | no TypeScript types found |
| Known vulns | 0 | 0 critical · 0 high · 0 moderate · 0 low (npm audit) |
Answers from our run
Does lru-queue install cleanly?
Yes. In a fresh container with an empty cache, npm install lru-queue finished in 2 seconds, leaving 10 packages and 4 MB on disk. npm audit reported no known vulnerabilities.
How much does lru-queue add to a browser bundle?
0.7 KB gzipped (1.5 KB minified) when the whole package is bundled for the browser with esbuild. Importing only part of it is usually smaller.
Does lru-queue work with both ESM and CommonJS?
Yes. Both import 'lru-queue' and require('lru-queue') worked in Node 22 in our run. The package is published as CommonJS.
Does lru-queue include TypeScript types?
No type declarations were found in our install, so TypeScript users need their own declarations.
lru-queue or lru-cache: which should you use?
lru-cache: Use it when the library should own values and enforce TTL or weighted size limits. lru-queue 0.1.0 took 2.1 seconds and 10 installed packages for a three-method string-ID queue in our sandbox, while storing no cached values.
When should you not use lru-queue?
This is a new cache. lru-cache owns values and has TTL, size limits, disposal hooks, async fetch, iteration, and TypeScript support.
Use it if
- Existing memoizee-style code keeps values elsewhere and only needs recency bookkeeping.
- All cache identities are plain strings, and returning one eviction ID is the desired contract.
- A synchronous three-method CommonJS helper is easier to preserve than replacing an old cache layer.
- You can pin version 0.1.0 and test the external store and queue together.
- This is a new cache. `lru-cache` owns values and has TTL, size limits, disposal hooks, async fetch, iteration, and TypeScript support.
- Keys include objects, symbols, or type-sensitive numbers. The README permits plain strings only.
- Expiry, stale reads, weighted capacity, hit statistics, peeking, or iteration are requirements. None is exposed by this queue.
- The project needs declared TypeScript types or native ESM packaging. Version 0.1.0 has neither.
- Your dependency policy excludes dormant releases. npm published 0.1.0 in April 2014, and GitHub shows the last push in December 2022.
Setup reality
We installed lru-queue 0.1.0 in 2.1 seconds in a clean Node 22 Bookworm sandbox. The result was 10 packages and 4 MB on disk. The package itself has 1 direct dependency, 0 peer dependencies, 44 KB unpacked, and an MIT license. npm audit reported 0 known vulnerabilities. The extra packages come from es5-ext, which is a lot of graph for three queue methods.
No credentials, native compiler, config file, or postinstall setup is involved. The package is CommonJS and has no exports map. Both require() and ESM import worked on our box, but no TypeScript declarations were found. Its README still suggests CommonJS bundlers, including Browserify and Webmake, for browser use.
The factory returns opaque state with hit, delete, and clear; it does not hold cached values or expose size, membership, or iteration. Keep a separate Map, call hit on successful reads and writes, then delete the returned ID from that Map. Calling clear() only resets recency, so the external store must be cleared in the same operation.
IDs must be plain strings. Reusing an existing ID moves it to the newest position and returns undefined; adding a new ID beyond capacity returns the oldest ID. A full import produced a 1.5 KB minified, 0.7 KB gzipped browser bundle in our test, though the synchronous process-local queue offers no TTL, cross-process coordination, or async loading.
Patterns
Start a queue with a fixed capacity create-recency-queue
const createLruQueue = require('lru-queue')
const queue = createLruQueue(3)
queue.hit('alpha')
queue.hit('beta')
queue.hit('gamma')A capacity of 3 controls ID order only; the object has no value storage or size getter.
Remove the returned ID from a Map evict-external-cache
const values = new Map()
function cacheSet(id, value) {
values.set(id, value)
const evictedId = queue.hit(id)
if (evictedId !== undefined) values.delete(evictedId)
}When `hit` returns an ID, the queue has already forgotten it. Delete the corresponding value in the same code path.
Refresh recency after a cache hit refresh-cache-hit
function cacheGet(id) {
if (!values.has(id)) return undefined
queue.hit(id)
return values.get(id)
}Call `hit` only after `Map.has` succeeds, or the queue can contain an ID with no matching value.
Delete from both layers remove-cache-entry
function cacheDelete(id) {
queue.delete(id)
return values.delete(id)
}`queue.delete` has no Boolean result; return the result of `Map.delete` if the caller needs to know whether a value existed.
Reset values and recency clear-cache-state
function cacheClear() {
queue.clear()
values.clear()
}Both calls are required because `clear()` cannot reach the external `Map`.
Refresh an updated entry update-existing-entry
function cacheUpdate(id, update) {
if (!values.has(id)) return false
values.set(id, update(values.get(id)))
queue.hit(id)
return true
}A second `hit` for an existing string moves that ID to the recent end and returns `undefined`.
Reject a bad capacity early validate-queue-limit
function makeQueue(limit) {
if (!Number.isSafeInteger(limit) || limit < 1) {
throw new RangeError('cache limit must be a positive integer')
}
return createLruQueue(limit)
}The dependency coerces its limit through `es5-ext`; an explicit positive-integer check gives callers a useful error.
Namespace string identities namespace-string-keys
function userKey(id) {
return `user:${id}`
}
function orderKey(id) {
return `order:${id}`
}
cacheSet(userKey(42), user)
cacheSet(orderKey(42), order)The README restricts IDs to plain strings, so a prefix keeps user 42 distinct from order 42.
Observe the least recent ID handle-capacity-eviction
const queue = createLruQueue(2)
queue.hit('a')
queue.hit('b')
queue.hit('a')
console.log(queue.hit('c')) // 'b'Refreshing `a` makes `b` the least recent ID, so inserting the third distinct ID returns `b`.
Load the CommonJS factory from ESM import-from-esm
import createLruQueue from 'lru-queue'
const queue = createLruQueue(100)Our Node 22 ESM import worked, but version 0.1.0 has no exports map or native ESM entry.
Alternatives
More utils guides
lru-cache · ajv · type-fest · p-limit · find-up · js-yaml · the whole shelf →
How this guide is made: grounded in the library's documentation, release notes, changelog, and issue history, on a fixed rubric — not a hands-on install of every release. The 50 most-downloaded entries are additionally install-verified in clean containers. Corrections: contact the desk.