`allowed` modules in `no-nodejs-modules` should match the base name of the imported module

Background

I work in a monorepo where we don't use relative imports, but rather we have webpack configured to resolve imports to our JS source directory prior to looking in node_modules. For example, given a source directory of src/js, import "my/module" will resolve to src/js/my/module.js.

We have some directories in that JS source directory that match names of Node.js builtin modules. For example, we have a src/js/util/ directory, and in it we have things like src/js/util/debounce.js or src/js/util/escape.js. Doing import debounce from "util/debounce" currently triggers a no-nodejs-modules error, even though util/debounce is not a Node.js builtin (in fact, you can't import any Node util builtin through a subpath like that).

However, adding "util" to the array of allowed modules doesn't silence the error. The only way to silence it is to add an explicit entry for every file under the src/js/util/ directory (and its subdirectories). That's not tenable in a large codebase worked on by hundreds of engineers.

Proposal

I think the most straightforward thing would be to match the allowed behavior to the isBuiltIn behavior. Namely, the rule should expect each item in the allowed list to be a baseModule name.

I suppose the implementation would be:

• export baseModule from src/core/importType.js
• import it in src/rules/no-nodejs-modules.js
• Use allowed.indexOf(baseModule(name)) instead of allowed.indexOf(name) when checking the allowed list in that rule.

Concerns

This would be a breaking change if any users are currently using subpaths in their allowed lists to target only specific submodules. That said, I'm not familiar with any Node builtins where the convention would be to import a submodule with a subpath like util/<some-thing>. I'm not even sure if that's possible with any builtins (but I'm not a 100% authoritative source on the subject).

I'd be happy to open a PR, but I'd rather discuss it before doing that.