eslint-plugin-import: Rule `import/no-unresolved` raise false positive when there is no `main` field in the `package.json`

The pressure you’re discussing is not actually helping the ecosystem; i invite you to check the per-version download counts for every package that’s gone ESM-only. It’s a clear signal that developers do not want that.

The reason is because sindre is actually authoring their packages incorrectly - by omitting main entirely, there’s a default “main” of index.js, which execa and sort-keys have. The proper way to have an ESM-only package would be "main": false, which would then correctly create a warning for all of them.

Regardless of this plugin’s inevitable eventual support for ESM resolution - which should of course work - I would strongly encourage you to migrate to package authors that maintain compatibility over ones that attempt to subjugate their users by forcing them to use a specific subset of node’s available module systems.

@ljharb You claim false to be valid for main. Can you please cite your source?

The official docs for the field don’t mention false:

• https://docs.npmjs.com/cli/v6/configuring-npm/package-json#main
• https://docs.npmjs.com/cli/v7/configuring-npm/package-json#main
• https://docs.npmjs.com/cli/v8/configuring-npm/package-json#main
• https://nodejs.org/docs/latest-v12.x/api/packages.html#packages_main_entry_point_export
• v13 seems to lack that page ¯\_(ツ)_/¯
• https://nodejs.org/docs/latest-v14.x/api/packages.html#packages_main
• https://nodejs.org/docs/latest-v15.x/api/packages.html#packages_main
• https://nodejs.org/docs/latest-v16.x/api/packages.html#main
• https://nodejs.org/docs/latest-v17.x/api/packages.html#main

On the other hand, the nodejs.org pages list type as <string>. Plus, https://nodejs.org/docs/latest-v16.x/api/modules.html shows this pseudo code:

LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
   a. Parse X/package.json, and look for "main" field.
   b. If "main" is a falsy value, GOTO 2.
   c. let M = X + (json main field)
   d. LOAD_AS_FILE(M)
   e. LOAD_INDEX(M)
   f. LOAD_INDEX(X) DEPRECATED
   g. THROW "not found"
2. LOAD_INDEX(X)

1.b indicates that false would not that the package cannot be required but that index.js would be tried.

All package authored by @sindresorhus will be migrated to pure esm module see article It’s already the case for chalk and many other packages.

I have just upgraded a side-project to ESM – it consists of data-processing scripts and a Next.js app for data visualisations. Everything seems to be working with "type": "module" in package.json, thanks to experimental ESM support in ts-node and to a small temp hack in next.config.mjs.

For me, this unlocked execa@v6 , chalk@v5 and sort-keys@v5. All of these project dependencies are authored by sindresorhus and are ESM-only.

Although I have no runtime issues, importing chalk unexpectedly triggers ESLint:

import chalk from "chalk"; // ❌ Unable to resolve path to module 'chalk'. eslint(import/no-unresolved)

The other two very similar packages don’t produce any ESLint errors. Here are package.json of the versions I am using:

• ✅ https://unpkg.com/browse/execa@6.0.0/package.json
• ✅ https://unpkg.com/browse/sort-keys@5.0.0/package.json
• ❌ https://unpkg.com/browse/chalk@5.0.0/package.json

Does anyone see anything that would break import/no-unresolved only for chalk? 🤔

In the meantime, I’ll stick with "import/no-unresolved": "off" and will expect yarn lint:tsc to monitor imports.

P.S.: Pure ESM packages are somewhat painful, but I appreciate the migration pressure created by maintainers. The faster we move the ecosystem to ESM-only, the better for everyone. This year I had to explain differences between ESM and CommonJS to new devs and also assist with quite intricate repo configs. I hope all this knowledge becomes unnecessary for most folks by the end of 2022!

@ghoullier yes, i’m aware - and that’s very user-hostile and will break a ton of things, including this plugin.

I suggest switching to packages that preserve compatibility.

The same error occurs for the p-queue package which package.json only shows an exports field and no main field.

I agree that this is rather odd considering what is currently advised on the NodeJS site.

Yes, I do that as well. I just add a dummy main pointing to a ESM file to make this plugin work. CJS import will be broken anyways for ESM packages, so it does not matter whether main points to a valid CJS file.

Actually I point main to an ESM file in my projects. It still works well and will throw when the package is imported by require. I do think package authors need to add this field back, but eslint-plugin-import should reconsider add support for exports.

Anyway, thank you for your hard work!

Not reliably - because if the main is in a subfolder, that might have a package.json itself, it gets tricky. That’s a big part of why it’s a best practice for packages using exports to always explicitly expose package.json.

"./package.json": "./package.json".

and no, with a string exports nothing is exposed except the package name itself, that’s the whole point.

I’m sorry. A personal attack was not intended.

@ljharb Sorry about the personal attack from them. I’ll ignore it for now and monitor the bug that you have open on it. Thanks for your hard work on this package!

@macabeus In the issue I have open with chalk this was the feedback from @sindresorhus:

main can be useful when you have backwards compatibility with CommonJS. Chalk does not support CommonJS, so it makes no sense to specify it when exports is the proper way to define entry points. I don’t plan to add main just because the maintainer of the import ESLint plugin is difficult (he usually is). Source

He seems to have a valid point regarding throwing this linting error on a package that is not backwards compatible with CommonJS. Thoughts? I’m just stuck in the middle.

@kachkaev I have this same issue. I opened an issue with chalk. Looks like it’s because "main": "./source/index.js", is missing from package.json. Chalk with ESLint & Airbnb Base #536

@rasenplanscher mkdir -p node_modules/main-false && echo '{"main": false}' > node_modules/main-false/package.json && touch node_modules/main-false/index.js && node -pe "require.resolve('main-false')" does show that you’re right. I’ll add a test case to resolve for this.

That still makes “omit main entirely” an incorrect approach, unless there’s no index.js present - which the packages mentioned above have.

In that case, my testing shows that setting main to {} will, at least, error in every node version down to 0.10 (0.6 and 0.8 still default to index.js in that case), and “exports” takes precedence over this incorrect “main” in node versions that support it. Probably a better alternative, then, is to have an explicit main that points to a file that exists, but throws a runtime error immediately upon being required.

I mean, that package is super broken because it has a “main” that doesn’t exist - it should specify "main": false if it’s not meant to be importable. You may want to file a bug on it.

That said, we should be using package.json, not the main, to verify import type packages, so i think that’s the fix here.

There are the same lint errors even when using false.