Improve module resolution

Tell us about your environment

• ESLint Version: v4.16.0
• Node Version: v9.4.0
• npm Version: v5.6.0

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

This is a follow-up of #9746. See this repository, which explains the issue: chrisblossom/eslint-issue-9746

What did you expect to happen?

ESLint should be able to work inside Lerna projects.

What actually happened? Please include the actual, raw output from ESLint.

ESLint throws errors regarding module resolutions.

As described here (https://github.com/eslint/eslint/issues/9746#issuecomment-356810436) it seems that this is the expected behaviour, however I’d argue that the changes presented here: #9896 are actually improving the module resolution logic, while fixing #9746.

First, it splits up the extraLookup path into multiple paths where modules should be looked for, according to Node module specifications.

Secondly, the change to getBaseDir seems pretty straightforward: the projectPath should not be a node_modules directory.

If those changes are accepted, it would actually resolve issues users have with ESLint and Lerna, while improving the module resolution logic.

[not-an-aardvark]

That does help. However, I am still confused about how this affects user-facing behavior in general, because you’re describing it in terms of implementation details such as getBaseDir and extraLookup, which users wouldn’t be aware of.

Again, this issue is intended to discuss the external behavior that users would see, not the implementation. If we were to put an entry in the changelog that says “Updated the return value of getBaseDir”, this would not be useful to users, because getBaseDir is an implementation detail that users generally don’t know about. On the other hand, if we were to put an entry in the changelog that says “Update config resolution to also search for shareable configs from the location of the files being linted”, then this would be more useful to users because they would understand how this change affects them.

I am looking for the second kind of description for this change. You’re proposing a change to user-facing behavior, and it might be worthwhile, but I can’t tell because I’m not sure what the proposed change actually does. I’m asking for a general description of how the proposed change affects users, without referencing implementation details such as getBaseDir.

[ngotchac]

But wouldn’t it rightly make sense to take the eslint-config-foo the closest to the config-extension.json? I guess if a user installs the same module but different versions at the root of the project and in the config sub-directory, he would expect ESLint to choose the version of the config sub-folder.