[import/no-unresolved] not working for index.js

[a-x-]

similar but different: #1124

file struct:

utils/
    index.js
components/
    Foo.jsx
.eslintrc.js
webpack.config.js

utils/index.js:

export function getPromise () { return 42; }

components/Foo.jsx:

import { getPromise } from 'utils';

.eslintrc:

{
  "parser": "babel-eslint",
  "plugins": [
    "import",
  ],
  "settings": {
    "import/resolver": {
      "webpack": {
        "config": path.resolve(__dirname, "webpack.config.js"),
      }
    },
  },
  "rules": {
    "import/no-unresolved": ["error", {commonjs: true, caseSensitive: true}],
    // ...
  }
}

webpack.config.js:

{
  context: root,
  resolve: {
    modules: [root, 'node_modules'],
    extensions: ['.js', '.jsx', '.json', '.coffee', '.cjsx'],
  },
  // ...
}

versions: all are latest

[ljharb]

How does utils work when it's not inside node_modules?

[a-x-]

due to webpack aliasing and module paths:
modules: [root, 'node_modules']
root here contains utils dir along with all the shown fs structure.

[a-x-]

No one wanna write awful '../../../../MyComponent' imports, right? :)

[ljharb]

I do - I think they're a correct and proper indication that I have code that needs extracting into a separate package :-)

In this case, tho, the error message is warning you about capitalization. If you import from utils/index.js, what happens?

[a-x-]

utils/index.js and utils/index work
capitalization is correct as I can check (ls src)

[a-x-]

extracting into a separate package

Yes, but package can be local (that is well-known practice called Vendoring as I know),
so I setups webpack to looking for modules not in the node_modules only

dependency path variable is common computer engineering practice too

[ljharb]

You can and should vendor into node_modules itself and use bundledDependencies to tell npm to ignore that folder; it’s not a good practice imo to create alternate or different directories for third party code.

However, the utils issue is interesting. I’d still expect it to work and the implication is that there’s either a bug we need to fix, or that there’s something weird with capitalization of your files or case sensitivity of your machine.

[a-x-]

That's interesting solution... We'll think about it.

I have default macOS config. MacOS suggests case-insensitive FS setting by default.
Anyway, I can check case in my github repo. so utils/index.js is not capitalized 🤔

[a-x-]

That's interesting solution... We'll think about it.

really we're think that both tricks with moving all our directories into node_modules,
and using paths with ../../../ are highly weird.

all our friends use absolute paths as single useful way to fight the path complexity (simplify refactorings, decrease code blowing and etc.)

I can help fix that maybe, if you can help with details

[a-x-]

Currently I disabled caseSensitive option, but it's not ideal solution for us.

True-negative checks with caseSensitive: true are useful for my team

[ljharb]

Using absolute paths tends to couple things to specific developer’s machines (since all your files should only be inside $HOME); it’s not a good practice.

There’s definitely a bug here, and yes it’d be great to get a PR for it.

[a-x-]

Excuse my inaccuracy

I'm not about /Users/mxtnr/projects/project/blah/blah/Foo.jsx
I'm about blah/blah/Foo.jsx
rather than ../../../blah/Foo.jsx

[Germain67]

Any news on this? We encountered the same issue in our project.

[OoDeLally]

How do people solve this issue as of today?

[a-x-]

@OoDeLally, I fixed it for most cases with that workaround:
#1292 (comment)

but my project has not case mismatches.

so I wanna to get caseSensitive: true config back because some juniors can cause some naming/import case mismatching problems in the future.

[xianshenglu]

usually I'd like to write code like import utils from '@/utils' rather than import utils from '@/utils/index.js'.