Consistency of prototype chain lookup for parameters

[LiviaMedeiros]

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.

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

[aduh95]

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]

Dug up a bit: this problem was found, discussed and added to tsc-agenda Issues and PRs to discuss during the meetings of the TSC. some time ago:

• fs: simplify copy operations and more cleanups #31038
• https://github.com/nodejs/TSC/blob/main/meetings/2020-10-01.md#nodejsnode

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:

1. Can we decide which approach is preferable for new APIs (or refactorings in new PRs), when it's possible to choose?
2. 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?

[BridgeAR]

@LiviaMedeiros thanks for reminding me.