Cannot read properties of undefined when requiring node:fs with hooks

Version

v22.20.0, v23.11.1, v24.8.0

Platform

Linux exports-undefined 6.8.0-84-generic #84-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep  5 22:36:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

module

What steps will reproduce the bug?

register.mjs:

import { registerHooks } from 'node:module';
import { fileURLToPath } from 'node:url';
import { dirname, join } from 'node:path';

function resolve(specifier, context, nextResolve) {
	const path = fileURLToPath(import.meta.url);
	const dir = dirname(path);
	switch (specifier) {
		case 'fs':
		case 'node:fs':
			specifier = join(dir, 'fs-mock.mjs');					
	}

	return nextResolve(specifier, context);
};

registerHooks({ resolve });

fs-mock.mjs:

export const constants = {
	F_OK: 42
}

index.cjs:

const fs = require('node:fs');
console.log(fs.constants.F_OK);

Run node --import=./register.mjs index.cjs.

How often does it reproduce? Is there a required condition?

Happens reliably when fs is being required as node:fs, does not happen when required as fs, or when imported.

What is the expected behavior? Why is that the expected behavior?

Should either require fs-mock.mjs, or require original (builtin) fs module.

What do you see instead?

node:internal/modules/cjs/loader:1155
  return mod.exports;
             ^

TypeError: Cannot read properties of undefined (reading 'exports')
    at loadBuiltinWithHooks (node:internal/modules/cjs/loader:1155:14)
    at Function._load (node:internal/modules/cjs/loader:1197:20)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
    at Module.require (node:internal/modules/cjs/loader:1463:12)
    at require (node:internal/modules/helpers:147:16)
    at Object.<anonymous> (/vagrant/index.cjs:1:12)
    at Module._compile (node:internal/modules/cjs/loader:1706:14)
    at Object..js (node:internal/modules/cjs/loader:1839:10)
    at Module.load (node:internal/modules/cjs/loader:1441:32)

Additional information

Output from NODE_DEBUG=* node --import=./register.mjs index.cjs:
log.txt

You are mocking the fs module in ESM but the original is CommonJs

Thanks for the suggestion, but I don't think that's it:

It works when I replace require('node:fs') with require('fs'), without changing the contents of fs-mock.mjs. It evens works when I directly require('mock-fs'), or when I require('dummy') and change the resolution logic accordingly.
When I add a throw statement at the top of fs-mock.mjs, no error is thrown, which would seem to indicate that fs-mock.mjs never even gets loaded. Update: Just to make extra sure, I revoked all read access to fs-mock.mjs, but there is no EACCES. This confirms the module never gets loaded at all.

I know that Node's module resolution and loading code takes a different path for loading core modules when using require. I think this bug has to do with that.

I tried debugging Node.js core and observed the same behavior you’re discussing—not only for "node:fs", but for any specifier that starts with "node:". Even a custom specifier like "node:scoheart" hits the same path.

Concretely, every "node:" request enters the conditional StringPrototypeStartsWith(request, 'node:'), then proceeds into loadBuiltinWithHooks, and eventually attempts to load via loadBuiltinModule. The relevant source looks like this:

// node/lib/internal/modules/cjs/loader.js

function loadBuiltinWithHooks(id, url, format) {
  if (loadHooks.length) {
    url ??= `node:${id}`;
    // TODO(joyeecheung): do we really want to invoke the load hook for the builtins?
    const loadResult = loadWithHooks(
      url,
      format || 'builtin',
      /* importAttributes */ undefined,
      getCjsConditionsArray(),
      getDefaultLoad(url, id)
    );
    if (loadResult.format && loadResult.format !== 'builtin') {
      return undefined;  // Format has been overridden, return undefined for the caller to continue loading.
    }
  }

  // No hooks or the hooks have not overridden the format. Load it as a builtin module and return the exports.
  const mod = loadBuiltinModule(id);
  return mod.exports;
}

Module._load = function(request, parent, isMain) {
  ...
  const { url, format, filename } = resolveForCJSWithHooks(request, parent, isMain);

  // For backwards compatibility, if the request itself starts with node:, load it before checking
  // Module._cache. Otherwise, load it after the check.
  if (StringPrototypeStartsWith(request, 'node:')) {
    const result = loadBuiltinWithHooks(filename, url, format);
    if (result) {
      return result;
    }
    // The format of the builtin has been overridden by user hooks. Continue loading.
  }

  const cachedModule = Module._cache[filename];
  ...
}

What I see at runtime:

request === "node:fs" with no hooks registered, resolveForCJSWithHooks returns:

{
  url: "node:fs",
  format: "builtin",
  filename: "fs"
}

This leads to loadBuiltinModule("fs"), which returns the built-in fs module as expected.

request === "node:fs" with custom hooks registered, resolveForCJSWithHooks returns:

{
  url: "file:///Users/scoheart/Code/opensource/node/mytest/fsmock.mjs",
  format: undefined,
  filename: "/Users/scoheart/Code/opensource/node/mytest/fsmock.mjs"
}

Because the original request still starts with "node:", it still enters the if (StringPrototypeStartsWith(request, 'node:')) branch and calls:

loadBuiltinWithHooks(
  filename, // id === "/Users/.../fsmock.mjs"
  url,      // "file:///Users/.../fsmock.mjs"
  format    // undefined
)

loadBuiltinModule(id) // here id is the filename path —— "/Users/.../fsmock.mjs"

Since id is now an absolute path (not a known builtin like "fs"), loadBuiltinModule("/Users/.../fsmock.mjs") fails—there is obviously no builtin module by that name—leading to the error I’m seeing.

I’m not entirely sure whether this should be considered a bug or simply the intended behavior of the "node:" scheme plus the “backwards compatibility” branch in _load.

Question to maintainers

Is this the expected, intentional behavior for "node:" specifiers (including custom ones), or should custom "node:" specifiers be treated differently so they don’t fall through to loadBuiltinModule unless they resolve to an actual builtin?

I think in this case, it should use the overriden resolution result as expected. I have a fix in https://github.com/joyeecheung/node/tree/fix-node-hooks though I will need to further test it with the load hooks before sending a PR.

I have a fix

Nice 👍 I hope that gets merged soon, then.

module: fix sync resolve hooks for require with node: prefixes

@joyeecheung

@joyeecheung Has this landed yet? With node 25.3.0 I'm still seeing the same problem...

The fix is out in 25.4.0 so you will need to upgrade to test it.

It works now. Thank you for taking care of this so quickly. 👍 +1 karma points from me. 😌

Thanks, karma is what I am after!

chore: bump node.js minimum version to 25.4

module: fix sync resolve hooks for require with node: prefixes

Navigation Menu

Repository navigation

Cannot read properties of undefined when requiring `node:fs` with hooks #60005

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Question to maintainers

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cannot read properties of undefined when requiring node:fs with hooks #60005

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

timfish commented on Oct 2, 2025

BadIdeaException commented on Oct 4, 2025

Scoheart commented on Oct 5, 2025

Question to maintainers

joyeecheung commented on Dec 6, 2025

BadIdeaException commented on Dec 15, 2025

BadIdeaException commented on Jan 26, 2026

joyeecheung commented on Jan 26, 2026

BadIdeaException commented on Feb 8, 2026

joyeecheung commented on Feb 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Cannot read properties of undefined when requiring `node:fs` with hooks #60005