module: make module.parent truthy when loaded from ESM

[aduh95]

This is to ensure backward compatibility of CJS modules checking the
boolean value of module.parent to test if the module is the entry
point of the current process.

Currently, module.parent provides a way for CJS users to get which CJS modules required the current module first. This feature – not very useful by itself – is also (wrongly) used to make assumption about the program entry point. Some packages wrap their test code inside a if(!module.parent) condition, assuming that a falsy value means the module is run from CLI. The issue with this pattern is that the assumption doesn't work as soon as the module interacts with ESM or REPL.

The issue I'd like to address is when a dependency is using the if(!module.parent) pattern to run its tests, and the test code gets executed for ESM users without their knowledge; those tests that may have side effects and make the end user code fail without obvious reason.
The current behavior where module.parent is undefined therefore falsy impacts end users trying to migrate from CJS to ESM, not the package author using such pattern in one of their abandoned project. This PR switches to a dummy object which makes it truthy.

Refs: #33534

[targos]

Can you share an example of a package that does it?

[aduh95]

I encountered that with pdf-parse, I don't know how rare is it – the fact that we haven't receive any report except mine seems to indicate it's not a very spread out issue.
But it's really frustrating to stumble upon this, I'd bet most users who try out switching to ESM and use a package that uses this kind of pattern would simply go back to CJS.

[ljharb]

pdf-parse now seems to use module.parent as "debug mode" and no longer throws: https://gitlab.com/autokent/pdf-parse/-/blob/master/index.js#L6

does that resolve your original issue?

[aduh95]

does that resolve your original issue?

Hum, no the issue is still there: https://gitlab.com/autokent/pdf-parse/-/issues/15. But if I'm opening this PR, it's not to fix my old issue with that package, it's to address the more general point: do we want to support this pattern, or do we prefer to keep the current broken behavior? As I said in the OP and the other PR, I think the current behaviour only harms users that are willing to try out ESM, and I'd like to improve that.

[ljharb]

I don't think it only does that - it also reinforces that this pattern shouldn't be used. It's unfortunate that https://gitlab.com/autokent/pdf-parse/-/merge_requests/3/diffs is still open; is that package still maintained?

[devsnek]

aren't we in the middle of runtime deprecating module.parent?

[aduh95]

aren't we in the middle of runtime deprecating module.parent?

Indeed: #33534

it also reinforces that this pattern shouldn't be used

Agreed, but in the mean time, the current behaviour hurts the wrong people: package users, rather than package authors.

[devsnek]

So yeah, we should definitely not merge this.

[aduh95]

It seems unnecessary to add this at this point, closing.