Description

According to this comment in the vite sourcecode, even if the exports map has a valid entry, it'll refuse to use it if it exists alongside the legacy fields, and if the exports map entry ends in .mjs.

Assuming this behaviour is still necessary for some packages, it still breaks for others.

For example: bwip-js

The exports map is thoroughly defined, but they need to define the legacy fields for backwards-compatibility for older codebases.

However, the legacy fields aren't sufficient enough to support ESM (as there's no legacy method for defining browser + esm + types), so they only support CJS via the legacy fields.

Packages like bwip-js should use the exports map where possible.

Suggested solution

In order to maintain the existing behaviour for packages that need it, there's two potential solutions

1. Have a whitelist config option to whitelist packages that the developer knows has a suitable exports map
2. Have a whitelist config option to whitelist packages that still have the "mjs files import cjs files" problem as defined in the vite sourcecode link

Both of these solutions would solve my particular use-case, but ultimately, the vite team would need to decide which is best for vite itself

Alternative

• resolve.alias to manually specify the resolution path to node_modules/bwip-js/dist/bwip-js.mjs
  • Relies on relative paths, not ideal in a monorepo when importing source (have to define the alias to the node modules folder of the monorepo package that you're importing)
• Yarn patch to rewrite the browser field in bwip-js
  • Hacky, requires storing the patch in the git repo, my team wasn't fond of that solution...

Additional context

No response

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.