eslint-plugin-import: `no-unresolved` is not aware of `exports` definition in `package.json`

I just published a resolver package that solves this issue using resolve.exports: https://www.npmjs.com/package/eslint-import-resolver-exports

It’s currently beta but seems to work for most of my projects. Feedback appreciated.

You can use https://github.com/import-js/eslint-import-resolver-typescript which supports exports in package.json instead.

I workaround the issue by using no-unresolved’s ignore option:

{
  // workaround for
  // https://github.com/import-js/eslint-plugin-import/issues/1810:
  "import/no-unresolved": ["error", { ignore: ["prosemirror-.*"] }],
}

Fixing resolve would be of much larger impact than a new resolver.

That should only be a suggestion for TS users; the real solution here is for resolve to add support for exports.

Of course, I didn’t close this issue. 🤣

@inlined if google wants to help make it happen faster, please feel free to visit https://github.com/browserify/resolve?sponsor=1

@inlined why would your Google SDKs be using exports, without main, in a way that’s not backwards-compatible??

I’m not wedded to any particular outcome, but it’s unacceptable to me that all discussion on the topic should be summarily silenced.

Not deleted by you then, but it was emailed to anyone who subscribes to this thread.

Your summary would be fine; your conclusion would only distract.

I would appreciate if you would allow my condensed argument to stand as a matter of public record. Please?

Hi @conartist6, I already have a working resolver I shared in my comment. I gladly accept contributions 😃

@vvo gitignore is so they don’t get committed; you DO want them published, which means you have to have a .npmignore that duplicates your gitignore but removes the lines that ignore build output.

For what it’s worth, here’s how I solved this situation for a package of mine.

The import style of the library is:

import { fn } from "mylib/next";
import { fn } from "mylib/express";

I updated my package.json build steps with:

{
    "prepublishOnly": "npm run build && cp next/dist/* next/ && cp express/dist/* express/",
    "postpublish": "rm next/*.d.ts next/*.js next/*.map next/*.mjs && rm express/*.d.ts express/*.js express/*.map express/*.mjs"
}

What this does is make copies of the build output files right before npm publish and remove them right after. A bit hacky but it definitely works and will ensure the package works well even on bundlers not supporting the exports: {} field of package.json.

Thanks to the maintainers of eslint-plugin-import for the very hard work they do.

We control our execution environment and do not need to be backwards compatible to versions that don’t support exports (every supported LTS of Node supports exports). Also, putting a root export would muddy project structure. It is quite common to have a /src and /lib folder for typescript projects. With exports it is quite understandable to remove lib from documented import paths.

We are using main. We also use exports for submodule paths so we can omit the lib folder generated by TypeScript.

For example, ./lib/v2/providers/https.js is exported at ./v2/https. See github.com/firebase/firebase-functions for more info.

I feel that you have abused your position as a moderator to protect your image in the face of reasoned dissent, so I can’t say I’m that thrilled with you at the moment.

I think the sane solution here is to don’t worry at all about any unmaintained Node.js version, it’s said, don’t provide support for anything older than Node.js v18.

Yup. Doing unpaid volunteer work doesn’t create a lot of free time.

I’m proposing to fix this by writing a new resolver. I’ve been experimenting recently (with great success, I feel) in making code sync/async agnostic by making aggressive use of the strategy pattern, which allows you to write functionally pure code which makes requests to and receives responses from a stateful core. Because that request/response mechanism is yield, the core is able to complete the request synchronously, or it may leave the generator suspended while it waits for async lookups to complete.

Would anyone be interested in collaborating me on a project like that if it would fix this issue once and for all?

do you have examples that we could look at?

Currently what’s in the readme is all I have. I think it’s best to use this as a fallback in addition to other resolvers as it only supports main, module, exports and nothing else. The readme shows how to use it with TypeScript resolver for example. You should probably keep using Webpack’s resolver too.

Check the resolve.exports docs for configuration options.

Thanks updated my comment to add committed. Also, I am using the “files: [“dist”, “express”, “next”]” setting of npm.

Indeed, but I don’t want to see these files in my editor (VSCode), they would still appear as grayed out I guess. But I will still add them to gitignore so they never get published committed.

@inlined i’m not “of the opinion that exports should not use renaming features”, i’m of the opinion that you have a really simple workaround while you wait.

None of my “opinions” are delaying exports support - the work is difficult and nobody else is doing it, and I have limited time. It will be done eventually.

Right - but that’s not backwards-compatible to pre-exports node. However, if you created an actual ./v2/https.js file that re-exported that provider, then not only would your package be backwards-compatible, but you wouldn’t be blocked on resolve getting exports support.