Order of keys in exports field matters to the resolved path

[niper1]

Using version 5.17.0

Hi guys!

I have an issue with resolving the path to one of our dependencies and have narrowed it down to that enhanced-resolve does not handle the exports field in package.json of said dependency. The path is resolved to the require path and not the import path when import is used.

package.json of the dependency:

...
"main": "./index.js",
  "module": "./esm/index.mjs",
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "require": "./index.js", // This one is picked
      "import": "./esm/index.mjs", // This one Should be picked
      "default": "./index.js"
    },
    "./package.json": "./package.json",
    "./*.css": "./*.css",
    "./*.scss": "./*.scss",
    "./lib": "./lib",
    "./lib/*": [
      "./lib/*",
      "./lib/*.js"
    ],
    "./*.js": {
      "import": "./esm/*.mjs",
      "require": "./*.js"
    },
    "./*": {
      "require": [
        "./*.js",
        "./*"
      ],
      "import": [
        "./esm/*.mjs",
        "./esm/*",
        "./*.js",
        "./*"
      ],
      "default": "./*"
    }
  },
...

Our implementation:

const RESOLVE_EXTENSIONS = ['.js', '.ts', '.tsx', '.jsx', '.json', '.mjs', '.cjs'];
const ALIAS_FIELDS = ['browser', 'module'];

private resolver = Resolve.create.sync({
		mainFields: [...ALIAS_FIELDS, 'main'],
		extensions: RESOLVE_EXTENSIONS,
		aliasFields: ALIAS_FIELDS,
		conditionNames: [
			'import',
			'esm2020',
			'es2020',
			'es2015',
			'require',
			'node',
			'node-addons',
			'browser',
			'default'
		]
	});

...

this.resolver({}, Path.dirname(parentFilePath), dependencyName);

The curious thing is that when swapping the order of the keys require and import in exports in the dependency, it works!

...
  "exports": {
    ".": {
      "types": "./index.d.ts",
      "import": "./esm/index.mjs", // import is placed first and suddenly it works. 
      "require": "./index.js",
      "default": "./index.js"
    },
...

Any ideas about what could be the issue here?

[alexander-akait]

You need to set fullySpecified: true, otherwise we can't know is it esm or not

[alexander-akait]

If you can create reproducible test repo I can look deeply

[niper1]

You need to set fullySpecified: true, otherwise we can't know is it esm or not

@alexander-akait Thank you for the quick reply! But I don't think that this is the way.

The fullySpecified option assumes that you want to resolve something that already has an extension but I want to resolve a package without one, e.g: @project-name/package-name. So, this option does not help this case.

[alexander-akait]

Sorry for the delay, I studied the documentation and I will say that such behavior is expected, your import should be higher than require -

Within the "exports" object, key order is significant. During condition matching, earlier entries have higher priority and take precedence over later entries. The general rule is that conditions should be from most specific to least specific in object order.

https://nodejs.org/api/packages.html#conditional-exports

Even in the node documentation the import is always higher than require. I would warn you that such an order may break more tools than you expect.

Feel free to feedback