Fix import type determination for monorepo setup w/ webpack resolver

[skozin]

Fixes #1597.

This PR changes the logic of isExternalPath function so that it doesn't consider the import name. For a path to be external, it's now sufficient that it matches one of the items in the import/external-module-folders array specified in settings.

This is to support a setup where some of the modules are symlinked from node_modules into directories elsewhere in the project (called "workspaces" in Yarn terminology). For example, it's common to have a monorepo setup like this:

node_modules
  @my-scope
    core -> ../../packages/core
    utils -> ../../packages/utils
packages
  core
    package.json
    index.js
  utils
    package.json
    index.js
package.json

Usually, one wants these packages to be treated as external since they're normally installed from a registry. Intuitively, this should be achieved by adding packages to import/external-module-folders array. However, this didn't work in a project that uses the webpack resolver.

The reason is that webpack resolver returns a fully resolved path to the module's main file, e.g. for @my-scope/core it would be something like /home/me/project/packages/core/index.js. This path doesn't contain the package name, @my-scope/core, as a substring, so isExternalPath would consider this path as internal prior to the changes proposed in this PR. This led to the import itself being considered as internal, as after merging #1294 a scoped import is determined as external only if its path is external too.

Apart from removing the import name check from isExternalPath, this PR also makes import/external-module-folders more strict. It won't match incomplete path segments anymore, so some/path won't match /my/awesome/path but will still match /my/some/path and /my/some/path/index.js. Also, if an item starts with a forward slash, it will be treated as an absolute path prefix, so /home/me/project/packages will only match the directory itself and everything inside it.

This PR doesn't break any existing tests, and I believe that it shouldn't break any existing setups either.

[skozin]

CI build is probably failing due to the failing ESLint checks of the plugin source and test code, but these checks were as well failing before this PR.

[coveralls]

Coverage decreased (-0.04%) to 97.835% when pulling b4d5fd3 on skozin:fix-order-for-monorepo-webpack-setup into 71e87da on benmosher:master.

[coveralls]

Coverage decreased (-4.2%) to 93.717% when pulling 2bb01c1 on skozin:fix-order-for-monorepo-webpack-setup into bcd9fe8 on benmosher:master.

[skozin]

Hmm, not sure why Coveralls reports that coverage of resolvers/node/index.js decreased, I didn't change or remove any tests or code related to that resolver.

[ljharb]

Looks great! just the one comment.

[skozin]

@ljharb, thank you so much for assisting me and merging this!