Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
136 changes: 136 additions & 0 deletions doc/api/module.md
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,141 @@ const require = createRequire(import.meta.url);
const siblingModule = require('./sibling-module');
```

### `module.clearCache(specifier, options)`

<!-- YAML
added: REPLACEME
-->

> Stability: 1.0 - Early development

* `specifier` {string|URL} The module specifier, as it would have been passed to
`import()` or `require()`.
* `options` {Object}
* `parentURL` {string|URL} The parent URL used to resolve the specifier. Parent identity
is part of the resolution cache key. For CommonJS, pass `pathToFileURL(__filename)`.
For ES modules, pass `import.meta.url`.
* `resolver` {string} Specifies how resolution should be performed. Must be either
`'import'` or `'require'`.
* `caches` {string} Specifies which caches to clear. Must be one of:
* `'resolution'` — only clear the resolution cache entry for this specifier.
* `'module'` — clear the cached module everywhere in Node.js (not counting
JS-level references).
* `'all'` — clear both resolution and module caches.
Comment on lines +85 to +89
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need this feature, or could we leave this customization out for now?

To fully understand the resolve cache case - this means we clear the resolution for specifier, parentURL, attributes only right? It seems to me like that has to be expected here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I notice this was marked resolved but it's not clear what the answer was?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please take a look at: 3021478

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately that commit removes attributes and not the caches option this was referring to.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joyeecheung would you be open to having the caches option be reconsidered for a follow-on? It would be good to hear the justification for this further. To align spec caching with this PR will be some work yet, and it would help if we can align on a simple model to start.

Copy link
Copy Markdown
Member

@joyeecheung joyeecheung Mar 28, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you mean to only have "all" semantics at all times? I think that's fine, resolution-only clearing is mostly for cache-busting resolutions.

To explain why I thought it would be useful to have separate module cahe clearing - while you don't want leaks, you also won't want use-after-frees and practices in vm.Script/vm.Module suggests that it works alright to allow V8 to retain the references, because once Node.js release them the rest are only retained through user code, when user module graph goes away it will go away, and libraries have been managing that alright. If you try to clear it while user code still rely on old modules you get use after frees and people will be annoyed. With cache busting solutions the library could use some help avoiding clearing the module cache too early even when the no longer allow new resolutions to old modules - and if they can't clear them separately they might be forced into a "leak-or-use-after-free" choice (even though resolution leak is usually minor compared to module leaks, so it's natural to choose resolution leak over module use-after-free which can be a lot more annoying)


Clears module resolution and/or module caches for a module. This enables
reload patterns similar to deleting from `require.cache` in CommonJS, and is useful for
hot module reload.

When `caches` is `'module'` or `'all'`, the specifier is resolved using the chosen `resolver`
and the resolved module is removed from all internal caches (CommonJS `require` cache, ESM
load cache, and ESM translators cache). When a `file:` URL is resolved, cached module jobs for
the same file path are cleared even if they differ by search or hash. This means clearing
`'./mod.mjs?v=1'` will also clear `'./mod.mjs?v=2'` and any other query/hash variants that
resolve to the same file.

When `caches` is `'resolution'` or `'all'` with `resolver` set to `'import'`, all ESM
resolution cache entries for the given `(specifier, parentURL)` pair are cleared regardless
of import attributes. When `resolver` is `'require'`, the specific CJS relative resolve
cache entry for the `(parentDir, specifier)` pair is cleared, together with any cached
`package.json` data for the resolved module's package.

Clearing a module does not clear cached entries for its dependencies. When using
`resolver: 'import'`, resolution cache entries for other specifiers that resolve to the
same target are not cleared — only entries for the exact `(specifier, parentURL)` pair
are removed. The module cache itself is cleared by resolved file path, so all specifiers
pointing to the same file will see a fresh execution on next import.

#### Memory retention and static imports

`clearCache` only removes references from the Node.js **JavaScript-level** caches
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a possibility we could track this and emit a warning? Specifically, if we know that a module is only held at the javascript-level cache (e.g. dynamic import, etc) vs. if we know it likely would leak then we can emit a warning at the very least when clearing the cache may lead to a leak. Doesn't necessarily need to be done in this PR so consider it a non-blocking suggestion/question.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can take a look but we can tackle this after the initial version has landed. It's marked as "active development".

(the ESM load cache, resolve cache, CJS `require.cache`, and related structures).
It does **not** affect V8-internal module graph references.

When a module M is **statically imported** by a live parent module P
(i.e., via a top-level `import … from '…'` statement that has already been
evaluated), V8's module instantiation creates a permanent internal strong
reference from P's compiled module record to M's module record. Calling
`clearCache(M)` cannot sever that link. Consequences:

* The old instance of M **stays alive in memory** for as long as P is alive,
regardless of how many times M is cleared and re-imported.
* A fresh `import(M)` after clearing will create a **separate** module instance
that new importers see. P, however, continues to use the original instance —
the two coexist simultaneously (sometimes called a "split-brain" state).
* This is a **bounded** retention: one stale module instance per cleared module
per live static parent. It does not grow unboundedly across clear/re-import
cycles.

For **dynamically imported** modules (`await import('./M.mjs')` with no live
static parent holding the result), the old `ModuleWrap` becomes eligible for
garbage collection once `clearCache` removes it from Node.js caches and all
JS-land references (e.g., stored namespace objects) are dropped.

The safest pattern for hot-reload of ES modules is to use cache-busting search
parameters (so each version is a distinct module URL) and use dynamic imports for modules that need to be reloaded:

#### ECMA-262 spec considerations

Re-importing the exact same `(specifier, parentURL, importAttributes)` tuple after clearing the module cache
technically violates the idempotency invariant of the ECMA-262
[`HostLoadImportedModule`][] host hook, which expects that the same module request always
returns the same Module Record for a given referrer. The result of violating this requirement
is undefined — e.g. it can lead to crashes. For spec-compliant usage, use
cache-busting search parameters so that each reload uses a distinct module request:

```mjs
import { clearCache } from 'node:module';
import { watch } from 'node:fs';

let version = 0;
const base = new URL('./app.mjs', import.meta.url);

watch(base, async () => {
// Clear the module cache for the previous version.
clearCache(new URL(`${base.href}?v=${version}`), {
parentURL: import.meta.url,
resolver: 'import',
caches: 'all',
});
version++;
// Re-import with a new search parameter — this is a distinct module request
// and does not violate the ECMA-262 invariant.
const mod = await import(`${base.href}?v=${version}`);
console.log('reloaded:', mod);
});
```

#### Examples

```mjs
import { clearCache } from 'node:module';

await import('./mod.mjs');

clearCache('./mod.mjs', {
parentURL: import.meta.url,
resolver: 'import',
caches: 'module',
});
await import('./mod.mjs'); // re-executes the module
```

```cjs
const { clearCache } = require('node:module');
const { pathToFileURL } = require('node:url');

require('./mod.js');

clearCache('./mod.js', {
parentURL: pathToFileURL(__filename),
resolver: 'require',
caches: 'module',
});
require('./mod.js'); // eslint-disable-line node-core/no-duplicate-requires
// re-executes the module
```

### `module.findPackageJSON(specifier[, base])`

<!-- YAML
Expand Down Expand Up @@ -2010,6 +2145,7 @@ returned object contains the following keys:
[`--enable-source-maps`]: cli.md#--enable-source-maps
[`--import`]: cli.md#--importmodule
[`--require`]: cli.md#-r---require-module
[`HostLoadImportedModule`]: https://tc39.es/ecma262/#sec-HostLoadImportedModule
[`NODE_COMPILE_CACHE=dir`]: cli.md#node_compile_cachedir
[`NODE_COMPILE_CACHE_PORTABLE=1`]: cli.md#node_compile_cache_portable1
[`NODE_DISABLE_COMPILE_CACHE=1`]: cli.md#node_disable_compile_cache1
Expand Down
45 changes: 44 additions & 1 deletion lib/internal/modules/cjs/loader.js
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,8 @@ const kIsExecuting = Symbol('kIsExecuting');
const kURL = Symbol('kURL');
const kFormat = Symbol('kFormat');

const relativeResolveCache = { __proto__: null };

// Set first due to cycle with ESM loader functions.
module.exports = {
kModuleSource,
Expand All @@ -119,6 +121,8 @@ module.exports = {
kModuleCircularVisited,
initializeCJS,
Module,
clearCJSResolutionCaches,
deleteCJSRelativeResolveCacheEntry,
findLongestRegisteredExtension,
resolveForCJSWithHooks,
loadSourceForCJSWithHooks: loadSource,
Expand Down Expand Up @@ -223,7 +227,46 @@ let { startTimer, endTimer } = debugWithTimer('module_timer', (start, end) => {
const { tracingChannel } = require('diagnostics_channel');
const onRequire = getLazy(() => tracingChannel('module.require'));

const relativeResolveCache = { __proto__: null };
/**
* Clear all entries in the CJS relative resolve cache and _pathCache
* that map to a given filename. This is needed by clearCache() to
* prevent stale resolution results after a module is removed.
* @param {string} filename The resolved filename to purge.
*/
function clearCJSResolutionCaches(filename) {
// Clear from relativeResolveCache (keyed by parent.path + '\x00' + request).
const relKeys = ObjectKeys(relativeResolveCache);
for (let i = 0; i < relKeys.length; i++) {
if (relativeResolveCache[relKeys[i]] === filename) {
delete relativeResolveCache[relKeys[i]];
}
}

// Clear from Module._pathCache (keyed by request + '\x00' + paths).
const pathKeys = ObjectKeys(Module._pathCache);
for (let i = 0; i < pathKeys.length; i++) {
if (Module._pathCache[pathKeys[i]] === filename) {
delete Module._pathCache[pathKeys[i]];
}
}
}

/**
* Delete a single entry from the CJS relative resolve cache.
* The cache key is `${parent.path}\x00${request}` where parent.path is the
* directory containing the parent module (i.e. path.dirname(parentFilename)).
* @param {string} parentDir Directory of the parent module (path.dirname of filename).
* @param {string} request The specifier as originally passed to require().
* @returns {boolean} true if the entry existed and was deleted.
*/
function deleteCJSRelativeResolveCacheEntry(parentDir, request) {
const key = `${parentDir}\x00${request}`;
if (relativeResolveCache[key] !== undefined) {
delete relativeResolveCache[key];
return true;
}
return false;
}

let requireDepth = 0;
let isPreloading = false;
Expand Down
Loading
Loading