ESM: Unable to resolve path to module 'got' import/no-unresolved

[mahnunchik]

Unable to resolve path to module 'got' import/no-unresolved

// Unable to resolve path to module 'got'  import/no-unresolved
import got from 'got';

• got v12.0.0
• eslint v8.5.0
• eslint-plugin-import 2.25.3

[ljharb]

Do you have it installed? Are you getting that warning on the command line, or just in your editor? Is eslint installed locally, and not globally?

[mahnunchik]

"dependencies": {
    "got": "^12.0.0"
  },
  "devDependencies": {
    "@babel/core": "^7.16.5",
    "@babel/eslint-parser": "^7.16.5",
    "eslint": "^8.5.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-plugin-import": "^2.25.3"
  },
"eslintConfig": {
    "parser": "@babel/eslint-parser",
    "extends": [
      "airbnb-base"
    ],
    "parserOptions": {
      "ecmaVersion": 2021,
      "requireConfigFile": false
    }
  }

[ljharb]

Thanks, but that doesn’t answer my questions. Resolving requires everything be present in node_modules.

[mahnunchik]

Do you have it installed?

Yes

Are you getting that warning on the command line, or just in your editor?

Comandline and editor (vs code).

Is eslint installed locally, and not globally?

Locally, fresh install.

[ljharb]

Thanks!

In this case, the latest version of got drops support for CJS, and as such, can’t be resolved by our CJS-only resolution mechanism. If you’re using native ESM, this plugin won’t help you, because it’s designed for use with CJS, or transpiled ESM (Babel/TS).

If you downgrade to got v11, or switch to a package author that isn’t user-hostile, then you should see everything resolve correctly.

[mahnunchik]

ESM should work. CJS should be deprecated.

[ljharb]

That’s a strong and wildly incorrect opinion.

Native ESM has tons of downsides and offers no benefits over CJS. Both are first-class module systems in node, so yes, native ESM should work, but the ecosystem isn’t ready to support it yet.

I’m going to close this.

[nghiepdev]

Same issue with type-fest

import {Except} from 'type-fest';

Unable to resolve path to module 'type-fest'.eslintimport/no-unresolved

[ljharb]

Same problem, caused by the same maintainer - altho in that case, it doesn't have any runtime values, so you should be using import type.

[jsg2021]

Those modules that the no-unresolved rule fails to find appear to be missing main and only defining exports (as node documents).

[ljharb]

@jsg2021 yes, see #2331 (comment)

[jsg2021]

@ljharb sorry :} I was just deep in my own research trying to assist my finding. Forgot to double-check the thread. I've been lucky that I'm only now having to sort with these modules.

[silverwind]

I made a repro for this issue: https://github.com/silverwind/import-got

git clone https://github.com/silverwind/import-got.git
cd import-got
npm i && npm t

It seems there is a unresolvable situation where the package authors indirectly blames this module:

Pretty much any problem with loading this package is a problem with your bundler, test framework, etc, not Got.

But #2331 (comment) blames the module, so we come full cycle.

Is there any resolution in sight? Maybe @szmarczak can comment what the problem is with got's exports.

[jsg2021]

I made a repro for this issue: https://github.com/silverwind/import-got

git clone https://github.com/silverwind/import-got.git

cd import-got

npm i && npm t

It seems there is a unresolvable situation where the package authors indirectly blames this module:

Pretty much any problem with loading this package is a problem with your bundler, test framework, etc, not Got.

But #2331 (comment) blames the module, so we come full cycle.

Is there any resolution in sight? Maybe @szmarczak can comment what the problem is with got's exports.

that comment answered your question? Pure esm packages do not need this rule. Turn it off?

[silverwind]

I'm pretty sure eslint-plugin-import works fine with other pure-ESM packages when eslint is configured via sourceType: module, and I really don't want to disable the rule as it's valuable. There must be something specifically wrong with the got module (and others), that makes this plugin fail to resolve it.

(Meanwhile, I managed to remove my got dependency, so it's not a problem for me any more)

[jsg2021]

idk, but inspecting got... it has no "main" entry point (commonjs) and only an "exports" entry (esm) and no alt ("module"/"es:next"/etc) entry points... and the linked comment suggests the resolution algorithm only works for those commonjs/alt entry points. 🤷 just my understanding... i'm not a maintainer, just another user like you.

[silverwind]

Just guessing, but maybe it's because got has no index.js. For example another pure ESM module, https://github.com/sindresorhus/is-ip, is resolved fine by this plugin and it has a index.js, which by default is picked up by node's CJS resolution.

[jsg2021]

Just guessing, but maybe it's because got has no index.js. For example another pure ESM module, https://github.com/sindresorhus/is-ip, is resolved fine by this plugin and it has a index.js, which by default is picked up by node's CJS resolution.

yep. commonjs algo falls back to index.js at the root of no entry point is found in package.json

[JounQin]

So it's still related to exports field support, right?

[silverwind]

Yes, ultimately, the issue is that eslint-plugin-import does not seem to parse exports.

Interestingly, require.resolve which should be a CJS mechanism is able to resolve ESM modules correctly.

> require.resolve("got")
'/Users/silverwind/git/import-got/node_modules/got/dist/source/index.js'

Maybe eslint-plugin-import should just use require.resolve in this case to fix this issue.

[ljharb]

Again, ESM-only packages are the problem - this plugin supports transpiled ESM, and not native ESM. is-ip seems to work because the index.js and lack of main means pre-exports node would try and fail to load that file.

When resolve gains support for “exports”, it will support native ESM too.

While this support is quite overdue here, ESM-only packages remain exceedingly user-hostile, and i strongly suggest aggressively avoiding them. There’s always an alternative non-ESM-only (and thus better) package to choose.

[silverwind]

For some cases like a default import, it might be enough to just see if the request resolves to a file, without actually parsing it.

I'm pretty sure there is some bug in resolve.js where the code path does not end up in require.resolve with which resolution would have worked, but I think I'll just wait for actual ESM support instead of chasing this further :)

[ljharb]

It is a very explicit and intentional choice to avoid using the built-in require.resolve.