package.json "exports" field fallback array support

[tarnishablec]

Clear and concise description of the problem

Currently vite does not support fallback array in "exports" field in package.json, vite does support array type but when first entrypoint is not accessable, an error will show. webpack 5 has already has a implementation in Alternatives.

Suggested solution

add fallback array support

Alternative

No response

Additional context

"exports": {
    "default": {
      "import": [
        "./dist/index.esm.js",
        "./src/index.tsx"
      ],
      "require": "./dist/index.umd.js"
    }
  },

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[ygj6]

Vite uses resolve.exports to resolve exports

vite/packages/vite/src/node/plugins/resolve.ts

Lines 550 to 554 in 024a2de

	// resolve exports field with highest priority
	// using https://github.com/lukeed/resolve.exports
	if (data.exports) {
	entryPoint = resolveExports(data, '.', options, targetWeb)
	}

But it does not support alternatives, it will only return the first path in the array:
https://github.com/lukeed/resolve.exports/blob/master/src/index.js#L5-L24
I did not find other suitable library to resolve exports to replace resolve.exports.

Alternatives is a great feature, I want to contribute it，I have two thoughts:

1. should let resolve.exports return an array and let vite choose a path that can be used
2. resolve.exports is no longer used, but let vite to implement the resolve of exports

@Shinigami92 @patak-js
what do you think, give me some suggestions.

[Niputi]

I think this should be made at the library.
I remember reading a conversation on twitter Evan had that there should be a library for making a standard way of reading the exports and resolve.exports got made for this purpose.
with a github search, it can be seen at wmr, marko, dvlp and vite uses this library

[tarnishablec]

resolve.exports

resolve.exports is a NO file-system reliance library, so I think technically it can not implement alternatives itself.

let resolve.exports return an array and let vite choose a path that can be used will be more practicable.

[bluwy]

There's a issue upstream for this: lukeed/resolve.exports#17

[privatenumber]

FYI Currently, Node.js does not fallback to trying the next path if one is unresolvable. In addition to Webpack, TypeScript seems to support this too (source).

Discussion here:
nodejs/node#37928 (comment)

[aleclarson]

The maintainer of resolve.exports seems too busy to care for the package lately. We should fork the package and give it a facelift. It could use a rewrite in TypeScript, Prettier formatting, Vitest suite, and less code golfing (easier to read).

[privatenumber]

I actually implemented exports/imports resolution with all the bugs from resolve.exports fixed:

https://github.com/privatenumber/resolve-pkg-maps

[aleclarson]

See #10504

[lukeed]

This is supported in resolve.exports@next, which will be released as 2.0 stable in the next few days

[bluwy]

Note: Vite has upgraded to resolve.exports 2.0, so this feature request is unblocked. I'm putting this to the Vite discussion though to decide if we should:

1. Follow node's behaviour of only validating the path, e.g. ['std:module', './file.js'], pick second.
2. Follow webpack's & typescript's behaviour of hitting disk checking existence, e.g. ['./missing.js', './file.js'], pick second.

I'm leaning towards no1 to follow the spec, but also I'm not sure why packages would export missing files if no2 is supported.

[bluwy]

In the last team meeting, we've decided to follow node as it defines the exports behaviour. And since node doesn't implement file existence checks, we will also not implement it.

In the original issue description, package.json's publishConfig should be used instead to define the fields before and after publish (dev and build).