fix: Avoid infinite loop scenario for self-linked module parents

[jkoudys]

I ran into an infinite loop, under a big stack of dependencies in another project. Jest was testing something using mongodb, which required a bunch of different connection modules, which require_optional'd "snappy", which it searched up in the package.jsons for. Unfortunately the project's root-level package.json appeared to link itself as its own parent, which hangs the entire instance in an infinite loop. It continually reads the package.json, sees there's no "peerOptionalDependencies" in it for the module it's looking for, then reloads the same package.json and tries again.

This fix takes the safe approach and sets the currentModule to null, if its parent is itself. It's not necessary we know all the scenarios that can cause this, only that it did happen, so it should throw an exception. The current exception for when the while (currentModule) loop is done will now be thrown.

[stieg]

Came here to submit this patch but you beat me too it @jkoudys. Wondering where the maintainer is. Did you ever figure out why jest does this (or if jest is the culprit). I'm still digging into this myself.

[stieg]

FYI: The issue in Jest: jestjs/jest#5235

[jkoudys]

@stieg good find. I'm wondering if this project is abandoned - if so it ought to be released, but personally I find the whole concept a bit of a hack. I'd be happy if mongoose tried to move on without this dependency.

While there's certainly jest behaviour that can trigger this (good find, btw!), I'm not seeing any official specs saying what module.parent should be. Sure a parent being itself breaks require_optional, but is it require_optional not supporting valid behaviour, or should the top-level module have null (or undefined?) as its parent. I've read through this thread, but didn't feel any closer to understanding by the end: npm/npm#8112

[stieg]

Pinged Christian on Twitter @jkoudys . Hopefully he will reply and get this merged when he has time.

[christkv]

Hey sorry for not responding before I've added matt broadstone to the conversation @mbroadst