When testcafe-hammerhead rewrites JavaScript it performs a significant amount of AST parsing and code generation. Rammerhead caches the rewritten output keyed by a hash of the original script so that subsequent requests for the same resource skip rewriting entirely. Two concrete cache implementations are available: an in-memory LRU cache and a disk-backed LRU cache.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/binary-person/rammerhead/llms.txt
Use this file to discover all available pages before exploring further.
RammerheadJSAbstractCache
The abstract base class both implementations extend. It exposes two async methods that all concrete caches must implement. You cannot instantiate this class directly.| Method | Description |
|---|---|
get(key) | Returns the cached rewritten JS string, or undefined on a miss. |
set(key, value) | Stores a rewritten JS string under the given cache key. |
RammerheadJSMemCache
An in-memory LRU cache backed bylru-cache. Cache size is enforced in bytes. When the cache is full, the least-recently-used entry is evicted to make room for the new one.
This is the default cache used by RammerheadProxy (50 MB). It is fast, requires no filesystem, and works in any deployment topology. Use it during development or when you run a single server process.
Constructor
Maximum total size of cached values in bytes. When the size limit is exceeded, LRU entries are evicted. The size of each entry is calculated as the byte length of the cached string.Common values:
50 * 1024 * 1024— 50 MB (default inRammerheadProxy)100 * 1024 * 1024— 100 MB200 * 1024 * 1024— 200 MB
Methods
get
Cache key (the hash of the original script).
set
Cache key.
Rewritten JavaScript string to cache.
RammerheadJSFileCache
A disk-backed LRU cache backed bylru-cache. Each cached script is written to a file named by its cache key inside a configured directory. The LRU marker is kept in memory; the actual content lives on disk. When an entry is evicted from the LRU, the corresponding file is deleted.
RammerheadJSFileCache supports an optional worker mode for cluster deployments where multiple Node.js workers share a single cache directory. In worker mode, only the master process writes to disk and maintains the LRU marker; workers send IPC messages to ask the master whether a key exists and to submit new entries.
Constructor
Absolute path to an existing directory where cached script files are stored. The directory must exist before the cache is constructed — the constructor throws
TypeError if it does not.Maximum total size of cached files in bytes. Enforced by the LRU marker using each file’s byte length.
Maximum number of cached files. When this limit is reached, the least-recently-used file is deleted.
When
true, enables cluster worker mode. The master process owns all disk I/O and LRU state. Worker processes communicate via IPC. Set to false when running a single process.Methods
get
Cache key.
The cached script content, or
undefined on a miss.set
Cache key.
Rewritten JavaScript string to persist.
Choosing the right cache
| RammerheadJSMemCache | RammerheadJSFileCache | |
|---|---|---|
| Persistence | None — lost on restart | Survives restarts |
| Multi-worker | Each worker has its own cache | Shared via IPC (worker mode) |
| Speed | Fastest | Slightly slower (disk I/O) |
| Setup | No config needed | Needs an existing directory |
| Best for | Development, single process | Production, clusters |