GeezerVison

If I’m reading this right, I find it troubling that if your project is sufficiently close to the disk root, the requirement of specifying rootDir is removed. It feels like where your fully-contained project directory is on disk should not affect program diagnostics—this seems like an easy way to get a compilation that succeeds in Docker because it was mounted at / but fails on the host machine, for example. I would lean toward a simple cause and effect: using X feature requires Y config, without any “weeeell technically” clauses. It also makes me wonder how much of this complexity can be removed. Why not use a simpler and more naive guess (config file path || current directory?) in the error case and save ~100 LOC?

If I’m reading this right, I find it troubling that if your project is sufficiently close to the disk root, the requirement of specifying rootDir is removed.

So... Sort-of. If the common path between the requesting file and the target file is the system root, then, yes. Every guess will be the system root, so there'll only be one unique guess. (Because it's the only possible root directory)

I don't think "mount location independence" is an aspect of our module resolver that it actually has - node_modules lookups trivially falsify that already. (Since you could mount somewhere that a parent node_modules that was used for resolution folder no longer exists.)

in the error case and save ~100 LOC?

Tbf, most of that is comments explaining why we don't actually know the final path and are making a guess. The actual guessing code is about 10 lines, changing the method wouldn't reduce it much, or even shrink the comment (just reduce how often it actually finds a file to pair with an error for better services behavior).