Support for package.json `exports` and `imports` ?

[bradennapier]

Sorry if this was posted, I did search quite a few things before posting :-P

So just came across this today, https://nodejs.org/dist/latest-v14.x/docs/api/esm.html#esm_packages - not sure how i missed it for so long but it appears that the internal imports mapping was just released in a recent .x version of v14.

Basically it allows node to resolve situations like Typescript paths would. There are a few cases here that seem like they are fairly advanced to handle properly, and it doesn't seem like it works at the moment, although just initial testing so far.

While I know that there are import resolvers that would allow defining the rules manually, since this is an official node feature already launched in the LTS version of node, it probably makes sense to support it with the default node resolver?

{
"name": "example",
"type": "module",
"exports": {
    ".": "./src/index.js",
    "./quick": "./src/quick.js"
  },
  "imports": {
    "#alias": "./alias.js",
    "#tryPeer": ["some-peer-dep", "./src/peer-not-found.js"],
    "#conditionally": {
          "node": "./src/node.js",
          "require": "./src/required.js",
          "import": "./src/imported.js",
          "default": "./src/defaulted.js"
     }
  }
}

Given the above, I can run the following in node (no feature flags needed)

// src/test.js

// loads src/quick.js due to exports "./quick" mapping pointing to "./src/quick.js"
import * as mods from 'example/quick'; 

// tries to load some-peer-dep package but if it fails it will load ./src/peer-not-found.js instead
import peer from '#tryPeer';

// if node env loads ./src/node, 
// if (not node) and required with require('example') loads ./src/required.js
// if (not node) and imported with import 'example' or import('example') loads ./src/imported.js
// if no match (dont think its possible here) , loads './src/defaulted.js'
import conditional from '#conditionally'

mods.runMain()
mods.runAlias()

// src/quick.js
export * from '#alias'; // exports all modules from './alias.js' due to internal imports mapping for #alias
export * from 'example'; // exports all modules from './src/index.js' due to exports "." mapping to "./src/index.js"

// src/index.js

export function runMain() {
   console.log('runs');
}

// ./alias.js

export function runAlias() {
    console.log('alias runs')
}

There is additional support for conditional handling which makes things a bit more complicated, but should potentially be considered.

With the import maps I believe it also allows importing subpaths if supported so that if you have #alias resolve to eslint then you could do import subpath from '#alias/lib/someFile.js'

I (think?) this is actually pretty similar to how deno handles module resolution mapping?

---

Running things with some flags to provide helper fns (no require.resolve by default) we do see:

 node --experimental-import-meta-resolve --experimental-top-level-await  ./src/test.js

// src/test.js
console.log(
  await import.meta.resolve('example'),
  await import.meta.resolve('example/quick'),
  await import.meta.resolve('#alias'),
);
// file:///.../example/src/index.js 
// file:///.../example/src/quick.js 
// file:///.../example/alias.js

---

Also just realized this even works if not using "type": "module" for standard require-based modules, although with require.resolve it doesnt return file path:

console.log(
  require.resolve('example'),
  require.resolve('example/quick'),
  require.resolve('#alias'),
);
// /.../example/src/index.js 
// /.../example/src/quick.js 
// /.../example/alias.js

[ljharb]

Yes, both should be supported (altho "imports" is super brand new, like, less than a week).

However, support first needs to be added in resolve - which I'm the primary maintainer of - and I'm planning to work on that during the month of August. Once that's updated, adding the support here should be trivial.

[bradennapier]

Awesome! Glad to hear it. Thanks for the reply. This issue can track its progress then!

Look forward to it.

[clintwood]

@ljharb any movement on this?

[ljharb]

@clintwood not quite yet - browserify/resolve#224 is still in progress, which would be the first step.

[clintwood]

@ljharb - I see - thanks for the feedback! Things have become a little complicated in nodeland 😉

[ctavan]

@ljharb will the modifications to the resolve module also fix package self references which make use of pkg.exports (they currently result in import/no-extraneous-dependencies errors)?

[ljharb]

@ctavan once resolve supports that, yes.

[nfantone]

Any workaround in the meantime? Getting import/no-unresolved errors on modules referenced by "exports", currently. Would defining custom aliases through eslint-import-resolver-custom-alias matching "exports" shape work?

[mattfysh]

Best workaround is just to turn off the rule until they add support for routing via package.json exports/imports fields

[ljharb]

A package that doesn’t provide equivalent CJS paths for exports paths isn’t back-compat and is thus being user-hostile, so this shouldn’t require workarounds most of the time.

[noahnu]

Best workaround is just to turn off the rule until they add support for routing via package.json exports/imports fields

If using Yarn Berry's PnP, you can use a custom resolver I wrote such as https://github.com/tophat/eslint-import-resolver-require (just delegates to require.resolve).

[mattfysh]

A package that doesn’t provide equivalent CJS paths for exports paths isn’t back-compat and is thus being user-hostile, so this shouldn’t require workarounds most of the time.

Not all packages are open source and made available for public consumption. In some closed development systems, a minimum version of nodejs is set allowing exclusive access to features such as subpath fields.

[ljharb]

True enough. Unfortunately those will have to use the above resolver or wait until proper exports support is added to resolve.

[bertho-zero]

Why not use https://github.com/webpack/enhanced-resolve which supports export fields instead of https://github.com/browserify/resolve?

resolve requests according to the Node.js resolving rules

I think modifying this file a bit should be enough, right?

[MikeG96]

I'm using this in eslint rules file

"import/no-unresolved": [2, { "ignore": ["^#[\\w\\d\/\\-]+$"] }]

[joezappie]

I had to modify @MikeG96's code to this to fully ignore these errors for imported modules with the # syntax:

"import/no-unresolved": [2, { "ignore": ["^#.+$"] }],
"import/extensions": 0

[ljharb]

@jrj2211 voicing support is unnecessary; there is a 100% chance this feature will eventually be implemented.

[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? #1810

[ljharb]

Indeed, duplicate of #1810.

[kellengreen]

Was support for this added? I'm still seeing import/no-unresolved when importing packages with exports.

[karlhorky]

I think this is not yet completed, but has been moved to #1810 - there are also multiple workarounds in that thread, including:

• switching to eslint-import-resolver-typescript #1810 (comment)
• adding eslint-import-resolver-exports for support with the current eslint-plugin-import #1810 (comment)

@ljharb, maybe the discussion in #1810 could be reopened to allow comments again?

[andyjy]

there are also multiple workarounds in that thread, including:

• switching to eslint-import-resolver-typescript #1810 (comment)

May help others: the final piece I required to solve Unable to resolve path to module from import/no-unresolved when importing typescript with eslint-import-resolver-typescript from other packages within my monorepo was to ensure I had a "default" key as the last entry under "exports" in package.json of the referenced package.