import/no-unresolved when using sass-module-importer

[magul]

In my project package.json I have:

{
 ...
  "devDependencies": {
    "eslint": "^6.8.0",
    "eslint-config-airbnb-base": "^14.0.0",
    "eslint-plugin-import": "^2.20.0",
    "sass-module-importer": "1.4.0",
  },
}

eslint.json

{
    "extends": "airbnb-base"
}

Importing

const moduleImporter = require('sass-module-importer');

works fine, but eslint raises import/no-unresolved.

As far as I debug it the root cause is that sass-module-importer package.json contains jsnext:main, which is preffered by a resolver used here, but at the same time sass-module-importer is not distributed with a file that jsnext:main points to.

Environment

$ node -v
v11.15.0
$ npm -v
6.7.0

[ljharb]

Indeed, that's a bug in sass-module-importer. It needs to either distribute src, or remove/fix jsnext:main.

[magul]

Hi @ljharb, I struggled for a while, where indeed I should report this issue. I ended reporting it here based on Node importing sass-module-importer just fine (so this package is in fact resolvable).

[ljharb]

It's incorrect data in their package.json; please do report it there.

If webpack, for example, silently falls back in this case to the "main", then perhaps we should too, but the real issue is in sass-module-importer, so it seems better to cure the disease instead of the symptoms.

[magul]

I created another issue in sass-module-importer. I want also to clarify that we're talking about node resolver here (as I'm import sass-module-importer in my gulpfile).

I understand your comment that

it seems better to cure the disease instead of the symptoms

but is that the design choice, that resolver used in eslint-plugin-import is more strict when resolving imports then the one used internally by Node and I should workaround it just by:

/* eslint-disable-next-line import/no-unresolved */

?

[ljharb]

hmm - jsnext:main isn't actually part of node's resolver, so it's a bit odd that our node resolver has it.

It was added in #132, seemingly as a workaround for not being able to validate commonjs exports (@benmosher, confirm?)