Consistency of prototype chain lookup for parameters

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 {}, mkdir must fail with ENOENT because it's not recursive.
When ran with { recursive: true }, stat must fail with ENOENT because 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 }).

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.

@BridgeAR

Dug up a bit: this problem was found, discussed and added to tsc-agenda Issues 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:

Can we decide which approach is preferable for new APIs (or refactorings in new PRs), when it's possible to choose?
Can we consider any change in this behaviour (which might happen frequently and implicitly) to be non-breaking, and any tests for it to be unwanted?

@LiviaMedeiros

@LiviaMedeiros thanks for reminding me.

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.

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.

Navigation Menu

Repository navigation

Consistency of prototype chain lookup for parameters #43401

Version

Platform

Subsystem

What steps will reproduce the bug?

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

What is the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Consistency of prototype chain lookup for parameters #43401

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?

What do you see instead?

Additional information

Activity

aduh95 commented on Jun 17, 2022

LiviaMedeiros commented on Jun 25, 2022

BridgeAR commented on Jun 25, 2022

github-actions commented on Jun 25, 2026

github-actions commented on Jul 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions