Repository navigation
Consistency of prototype chain lookup for parameters #43401
Description
Version
v19.0.0-pre
Platform
any
Subsystem
lib
What steps will reproduce the bug?
import fs from 'node:fs/promises';
const DIR = '/tmp/issue43401';
const defaultDirOptions = { recursive: true };
async function run(dirOptions) {
await fs.rm(DIR, { recursive: true, force: true });
console.log('dirOptions.recursive:', dirOptions.recursive);
try {
await fs.mkdir(`${DIR}/1/2/3/4`, dirOptions);
await fs.rm(DIR, dirOptions);
await fs.stat(DIR);
} catch(e) {
console.error(e);
}
}
await run({});
await run({ recursive: true });
await run(Object.create(defaultDirOptions));run() tries to create nested directories, then remove them, then access topmost one.
- When ran with
{},mkdirmust fail withENOENTbecause it's not recursive. - When ran with
{ recursive: true },statmust fail withENOENTbecause directory was deleted.
Depending on if we care that each property is "own", Object.create(defaultDirOptions) should behave either as (1) or as (2).
However, currently rm fails with EISDIR. So, mkdir is recursive but rm is not.
How often does it reproduce? Is there a required condition?
It depends on methods, it depends on version (pretty sure that some of these are changed within semver-patch level).
For some methods is might even depend on which property we access or on something even less related.
What is the expected behavior?
Consistency.
Or a warning somewhere, that only ownProperties are guaranteed to work.
Or an explicit agreement that it's UB "by design".
What do you see instead?
Inconsistency.
Additional information
In most cases, inherited properties are dropped by copying (e.g. { ...options }).
Activity
aduh95 commentedon Jun 17, 2022
I think only the only use case that has been considered is
user is passing a plain object; to me the "correct" answer should be "Node.js will use prototype inheritance and read non-enumerable properties", to be consistent with the ECMAScript spec.LiviaMedeiros commentedon Jun 25, 2022
Dug up a bit: this problem was found, discussed and added to tsc-agendaIssues and PRs to discuss during Technical Steering Committee meetings.
some time ago:
However, I couldn't find a further сontinuation in terms of resolving or documenting it. /cc @BridgeAR
Looks like the main argument for prototype lookups is that it is consistent with the ECMAScript specs and therefore with how things in JS usually work; and the main argument against it is that in Node.js core it is actively prevented to guard against prototype pollution.
Personally I don't think that a strict and urgent goal of having consistent behaviour across all currently existing APIs is worth the effort, churn and potential breakage. Assuming that, two questions remain open:
BridgeAR commentedon Jun 25, 2022
@LiviaMedeiros thanks for reminding me.
github-actions commentedon Jun 25, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 27, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.