import/no-unresolved is not recognizing installed modules that export "."

[TheJaredWilcurt]

All dependencies are on their latest versions. Errors:

  1:39  error  Unable to resolve path to module '@vue/test-utils'  import/no-unresolved
  4:29  error  Unable to resolve path to module 'vuex'             import/no-unresolved

Code:

import { createLocalVue, mount } from '@vue/test-utils';
import axios from 'axios';
import flushPromises from 'flush-promises';
import Vuex, { Store } from 'vuex';

import { mutations } from '@/store.js';

import App from '@/App.vue';

import { currentUser } from '@@/mockData/CommonMockData.js';
import mockUsersResponse from '@@/mockResponses/Users.js';

vuex is in the dependencies and @vue/test-utils is in the devDependencies in package.json. Both are installed and in the node_modules folder.

What's interesting is that they fail across all test files, but no other node_module imports fail. It's just these two.

eslintrc.js

const path = require('path');

module.exports = {
  root: true,
  parserOptions: {
    parser: '@babel/eslint-parser',
    ecmaVersion: 2022,
    sourceType: 'module',
    requireConfigFile: false
  },
  extends: [
    'tjw-import'
  ],
  settings: {
    'import/resolver': {
      webpack: {
        config: {
          resolve: {
            alias: {
              '@': path.resolve(__dirname, 'src'),
              '@@': path.resolve(__dirname, 'tests')
            }
          }
        }
      }
    }
  }
};

tjw-import can be seen here:

• https://github.com/tjw-lint/eslint-config-tjw-import/blob/main/index.js

[masi]

Do the package.json files have an "export" key to map exports to file names?

[TheJaredWilcurt]

// /node_modules/@vue/test-utils/package.json
...
  "main": "dist/vue-test-utils.js",
  "module": "dist/vue-test-utils.esm.js",
  "exports": {
    ".": {
      "default": "./dist/vue-test-utils.js",
      "require": "./dist/vue-test-utils.js",
      "import": "./dist/vue-test-utils.esm.js"
    }
  },
...

// /node_modules/vuex/package.json
...
  "main": "dist/vuex.common.js",
  "module": "dist/vuex.esm.js",
  "exports": {
    ".": {
      "module": "./dist/vuex.esm.js",
      "require": "./dist/vuex.common.js",
      "import": "./dist/vuex.mjs"
    },
    "./": "./"
  },
...

// /node_modules/axios/package.json
...
  "main": "index.js",
...

// /node_modules/flush-promises/package.json
...
  "main": "index.js",
...

The flush-promises and axios imports do not have a linting error, and do not have exports or module defined in their package.json.

[PierreJeanjacquot]

hey, I'm running into the same issue while importing @multiformats/multiaddr

the issue may comes from nested export of "."

@vue/test-utils

@multiformats/multiaddr

this syntax look good according to nodejs doc https://nodejs.org/docs/latest-v16.x/api/packages.html#package-entry-points but is no resolved by eslint-plugin-import

[TheJaredWilcurt]

Updated issue title based on this new information.

[ljharb]

Do they have a "main", though?

This plugin uses resolve, which does not yet support "exports".

[TheJaredWilcurt]

Updated previous example to answer question

[PierreJeanjacquot]

Thank you for the head up @ljharb No "main" neither in @multiformats/multiaddr I looked at the resolve source it seems neither the legacy "module" nor "exports" is supported From Node.js 12 having only "exports" is fine, "main" is only used as a fallback when the former is missing. Since the oldest Node.js maintained LTS is 14 "exports" should be the default resolution.

[FloV22]

issue occurs also with avajs

[TorinFrancis]

This issue also occurs with react-hook-form, which does have a "main" field. For some reason, the issue does not occur with webpack 4, only 5. The error in the debug log comes from an webpack dependency (that conflicts with a eslint-import-resolver-webpack dependency).

eslint-plugin-import:resolver:webpack Error during module resolution: Error: Package path . is not exported from package /Users/torinfrancis/projects/churro/node_modules/react-hook-form (see exports field in /Users/torinfrancis/projects/churro/node_modules/react-hook-form/package.json)
    at /Users/torinfrancis/projects/churro/node_modules/webpack/node_modules/enhanced-resolve/lib/ExportsFieldPlugin.js:104:7

I can resolve the issue by changing the react-hook-form package.json from

  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.esm.mjs",
      "require": "./dist/index.cjs.js"
    }
  },

to

  "exports": {
    "./package.json": "./package.json",
    ".": "./dist/index.esm.mjs"
  },

Of course, this isn't a real solution, but seems to indicate that it's specifically the conditional exports syntax that is a problem for the resolver

[MattIPv4]

👋 Just noting that I ran into this with graphql-request as well, which only has exports and not main:

...
  "exports": {
    ".": {
      "require": {
        "types": "./build/cjs/index.d.ts",
        "default": "./build/cjs/index.js"
      },
      "import": {
        "types": "./build/esm/index.d.ts",
        "default": "./build/esm/index.js"
      }
    }
  },
...

[ivorpeles]

Also happening with solid-js

[13OnTheCode]

Until 2023, the latest version of Node.js, 20.4.0, has arrived, yet people still refuse to embrace ESM. Why is that?

[ljharb]

@13OnTheCode because it's not actually better.

[Raynos]

Yeah it's the missing "main" field which causes an error on sql-template-tag package which appears to be ESM only and only has an exports set in the package.json

[chawes13]

I'm getting this error when trying to upgrade to the latestdate-fns package, which does have main defined in its package.json (in addition to exports). https://github.com/date-fns/date-fns/blob/a39b8058f777517e8040193ba597dff18765951a/package.json#L17

[ljharb]

@chawes13 indeed, that points to https://unpkg.com/browse/[email protected]/index.js which should work fine. Can you file a new issue for this one, since it's not related to "exports" support?

[JounQin]

@ljharb See #1479