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

bradennapier · 2020-08-05T04:31:26Z

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

The text was updated successfully, but these errors were encountered:

ljharb · 2020-08-05T05:35:00Z

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 · 2020-08-05T10:46:40Z

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

Look forward to it.

clintwood · 2020-09-07T06:55:52Z

@ljharb any movement on this?

ljharb · 2020-09-07T07:14:04Z

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

clintwood · 2020-09-07T15:34:04Z

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

With Node.js adopting a standard for packages to declare their exports, this rule may not be useful anymore. It should be legal to import any valid export from a package. An open [issue] on eslint-plugin-import tracks this ecosystem feature and when that resolves there may be a better rule to enable. [issue]: import-js/eslint-plugin-import#1868

ctavan · 2020-10-02T14:23:47Z

@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 · 2020-10-02T17:33:38Z

@ctavan once resolve supports that, yes.

nfantone · 2021-01-14T17:07:17Z

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 · 2021-06-20T05:53:54Z

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

ljharb · 2021-06-20T14:48:40Z

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 · 2021-06-20T15:58:46Z

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 · 2021-06-20T23:07:36Z

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 · 2021-06-21T00:34:25Z

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

bertho-zero · 2021-10-20T14:38:00Z

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 · 2021-11-05T22:57:01Z

I'm using this in eslint rules file

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

joezappie · 2021-12-11T01:28:42Z

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 · 2021-12-11T03:36:32Z

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

danielweck · 2022-02-23T00:30:58Z

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 · 2022-02-23T06:44:29Z

Indeed, duplicate of #1810.

kellengreen · 2024-04-03T06:06:12Z

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

karlhorky · 2024-04-03T10:33:17Z

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 no-unresolved is not aware of exports definition in package.json #1810 (comment)
adding eslint-import-resolver-exports for support with the current eslint-plugin-import no-unresolved is not aware of exports definition in package.json #1810 (comment)

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

ljharb mentioned this issue Aug 18, 2020

eslint-import-resolver-node can't handle "exports" #1884

Closed

This was referenced Apr 16, 2021

[core] Error when installing in unsupported node environments mui/material-ui#25798

Closed

[core] Use exports instead of aliases where possible mui/material-ui#25799

Closed

jwalton mentioned this issue May 14, 2021

4.2.0 breaks pre-14.x code janl/mustache.js#775

Open

This was referenced Jul 20, 2021

Rule import/no-unresolved raise false positive when there is no main field in the package.json #2132

Open

Add main to work around eslint-plugin-import issues Rich-Harris/periscopic#14

Merged

lmestel mentioned this issue Jul 30, 2021

WIP: use package exports kickstartDS/kickstartDS#272

Closed

CircleCode mentioned this issue Sep 8, 2021

missing main field in package.json tinyhttp/tinyhttp#312

Closed

nitsky mentioned this issue Sep 22, 2021

Strange behavior when importing JS library modelfoxdotdev/modelfox#34

Closed

hiranya911 mentioned this issue Dec 12, 2021

Cannot find module 'firebase-admin/app' firebase/firebase-admin-node#1488

Open

gamemaker1 mentioned this issue Dec 31, 2021

ESLint not able to resolve import - Error: unable to resolve path to module "express-rate-limit" express-rate-limit/express-rate-limit#277

Closed

winixt mentioned this issue Jan 26, 2022

fix: 解决 eslint-plugin-import 无法识别 exports imports 问题 WeBankFinTech/fes-design#41

Merged

swissspidy mentioned this issue Jan 26, 2022

Build packages using Rollup GoogleForCreators/web-stories-wp#10386

Merged

14 tasks

danielweck mentioned this issue Feb 23, 2022

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

Open

ljharb closed this as completed Feb 23, 2022

Namchee mentioned this issue Dec 5, 2023

fix(rules): temporarily disable import/no-unresolved Namchee/eslint-config-namchee#22

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Support for package.json exports and imports ? #1868

Support for package.json exports and imports ? #1868

Comments

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

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