Here's a weird one: If a webpack alias is named base it is ignored by eslint-import-resolver-webpack.
With the following configs:
// webpack.shared.config.js
// ...
resolve: {
alias: {
base: path.resolve(__dirname, PATH_SOURCE, '_patterns/00-base/'), // <-- see `base` here
atoms: path.resolve(__dirname, PATH_SOURCE, '_patterns/01-atoms/'),
molecules: path.resolve(__dirname, PATH_SOURCE, '_patterns/02-molecules/'),
organisms: path.resolve(__dirname, PATH_SOURCE, '_patterns/03-organisms/'),
templates: path.resolve(__dirname, PATH_SOURCE, '_patterns/04-templates/'),
pages: path.resolve(__dirname, PATH_SOURCE, '_patterns/05-pages/'),
},
},
// .eslintrc.js
// ...
settings: {
'import/resolver': {
webpack: {
config: 'webpack.shared.config.js',
}
}
}
And then implementations all around my code like:
// design-system.js
// ...
import * as base from 'base';
import * as alert from 'atoms/alert';
import * as card from 'molecules/card';
import * as article from 'organisms/article';
Will result in this eslint error for only base:
9:1 error 'base' should be listed in the project's dependencies. Run 'npm i -S base' to add it import/no-extraneous-dependencies
However, if I change all instances of base to derp, then we're gold:
// webpack.shared.config.js
// ...
resolve: {
alias: {
derp: path.resolve(__dirname, PATH_SOURCE, '_patterns/00-base/'), // <-- see `derp` here
atoms: path.resolve(__dirname, PATH_SOURCE, '_patterns/01-atoms/'),
molecules: path.resolve(__dirname, PATH_SOURCE, '_patterns/02-molecules/'),
organisms: path.resolve(__dirname, PATH_SOURCE, '_patterns/03-organisms/'),
templates: path.resolve(__dirname, PATH_SOURCE, '_patterns/04-templates/'),
pages: path.resolve(__dirname, PATH_SOURCE, '_patterns/05-pages/'),
},
},
// design-system.js
// ...
import * as derp from 'derp';
import * as alert from 'atoms/alert';
import * as card from 'molecules/card';
import * as article from 'organisms/article';
The above config works flawlessly with no eslint errors. So, TLDR:
Is base as reserved word to eslint?
Any chance you have a package named “base” installed locally?
I know this sounds crazy, but rolling back our version of Gulp to the pre-alpha.3 version makes this go away. Everything I know is a lie. Closing!
Perhaps the bad version of gulp has a dependency named “base” that ends up in the top level of your node_modules?
That's exactly what I'm thinking as well, testing immediately. (Also, super thank for a quick response!) Will report back what we dig up.
(Typically webpack aliases are best when they can’t possibly be real package names)

@ljharb WINS ^^