`no-unresolved` is not aware of `exports` definition in `package.json`

[ignatiusreza]

From this announcement

Package entry points and the package.json “exports” field

There are now two fields that can define entry points for a package: “main” and“exports”. The “main” field is supported in all versions of Node.js, but its capabilities are limited: it only defines the main entry point of the package. A new package.json field “exports” can also define the main entry point, along with subpaths. It also provides encapsulation, where only the paths explicitly defined in “exports” are available for importing. “exports” applies to both CommonJS and ES module packages, whether used via require or import.

Might need to be fix in resolve package..

[ljharb]

Indeed, that’s where it needs to be fixed.

However, for back compat, you should have a file at the location the exports key would otherwise resolve to anyways - so even when it’s fixed in resolve, you’d still want it fixed now.

[inlined]

Will this be resolved any time soon? We're going to have to yank no-unresolved from our Google code samples because it can no longer handle our SDKs.

[ljharb]

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

[inlined]

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.

[ljharb]

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.

[inlined]

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.

[ljharb]

@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.

[ljharb]

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

[vvo]

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.

[ljharb]

@vvo you can also .gitignore those files (don't forget to make an .npmignore and unignore them there) and avoid the need to remove them afterwards.

[vvo]

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.

[ljharb]

@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.

[vvo]

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

[danielweck]

Hi all, FYI I am successfully using this tiny ESLint import resolver to support ESM modules imports via package.json exports map:

https://gist.github.com/danielweck/cd63af8e9a8b3492abacc312af9f28fd

Duplicate issue? https://github.com/import-js/eslint-plugin-import/issues/1868

[bertho-zero]

I created a simple resolver that works thanks to enhanced-resolve:

resolver.js

'use strict';

const fs = require('graceful-fs');
const path = require('path');
const { builtinModules } = require('module');
const enhancedResolve = require('enhanced-resolve');
const CachedInputFileSystem = require('enhanced-resolve/lib/CachedInputFileSystem');

const builtins = new Set(builtinModules);

const nodeFileSystem = new CachedInputFileSystem(fs, 4000);
const defaultResolver = enhancedResolve.create.sync(opts());

function resolve(source, file, config) {
  if (builtins.has(source)) {
    return { found: true, path: null };
  }

  try {
    const resolver = config ? enhancedResolve.create.sync(opts(config)) : defaultResolver;
    const result = resolver(path.dirname(file), source);

    return { found: true, path: result };
  } catch (e) {
    return { found: false };
  }
}

function opts(config) {
  return Object.assign({
    fileSystem: nodeFileSystem,
    conditionNames: ['node'],
    extensions: ['.mjs', '.js', '.json', '.node'],
    preferRelative: true,
  }, config);
}

module.exports = {
  interfaceVersion: 2,
  resolve,
};

Usage (eslint.config.js):

// without config
module.exports = {
  // ...
  settings: {
    'import/resolver': path.resolve(__dirname, './resolver')
  },
  // ...
};

// with `enhanced-resolve` config
module.exports = {
  // ...
  settings: {
    'import/resolver': {
      [path.resolve(__dirname, './resolver')]: {
        extensions: ['.js', '.ts']
      }
    }
  },
  // ...
};

[linguofeng]

Any updates?

[DamienCassou]

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-.*"] }],
}

[piranna]

@bertho-zero it looks similar to https://gist.github.com/danielweck/cd63af8e9a8b3492abacc312af9f28fd, can you create a npm package from it?

[cyco130]

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.

[DamienCassou]

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

do you have examples that we could look at? I don't understand how to configure the resolver to get the same behavior as the one from the webpack resolver.

[cyco130]

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.

[JounQin]

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

[ljharb]

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

[JounQin]

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. 🤣

[stagas]

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.

Thank you @cyco130, that solved it for me.

[conartist6]

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?

[ljharb]

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

[cyco130]

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

[nia072011]

Why not use createRequire(importer).resolve(importee,{paths:[]}) directly? In order to support configuring extensions, try resolve importee.[ext] and importee/index.[ext] again.

[ljharb]

@nia072011 that wouldn't work in older node versions, and still wouldn't support ESM. It's not a terrible workaround tho pending the resolve implementation.