Support fallback to classic resolution when "exports" field resolution fails

[EnixCoda]

Description

I hope such new conditional option would benefit developers using Vite and some dependencies built from tools that does not support "exports" field yet.

My situation

This is a simplified model from my real project.

My project depends on a and a depends on b. Although b has exports field, a is still building with out-of-date toolchain that does not know about exports field, so a resolves b/dist/subpath/index.js without problem. If a respected exports field, it would have to import b/subpath/index.js instead.

My NPM package

{
  "dependencies": {
    "a": "^1.0.0"
  },
  "devDependencies": {
    "vite": "latest"
  }
}

// index.js
import "a";

NPM package a

{
  "name": "a",
  "module": "dist/index.js",
  "dependencies": {
    "b": "^1.0.0"
  }
}

// dist/index.js
import "b/dist/subpath/index.js";

NPM package b

{
  "name": "b",
  "module": "./dist/index.js",
  "exports": {
    "./*.js": "./dist/*.js"
  }
}

---

I got such error from Vite:

✘ [ERROR] Could not resolve "b/dist/subpath/index.js"

    node_modules/a/dist/index.js:
        │ import 'b/dist/subpath/index.js';
        ╵        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The module "./dist/dist/subpath/index.js" was not found on the file system:

    node_modules/b/package.json:
         │     "./*.js": "./dist/*.js",
         ╵            ~~~~~~~~~~~~~~~~~~

  You can mark the path "b/dist/subpath/index.js" as external to exclude it from the bundle,
  which will remove this error and leave the unresolved path in the bundle.

Suggested solution

I know there is a trend to use exports field and it really is beneficial in many ways. I do use to in my package as well! But in this situation, this becomes a blocker from using Vite.

Perhaps adding a new option to allow fallback to ignore resolution error of exports field, e.g. resolve.bearExportsError. When it is true, do not throw error from

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

Line 1038 in d0221cd

throw new Error(

I am not experienced in designing build tools so here my suggestion might be really naive. Hope I have clarified my situation well and you could figure out a better idea for this problem.

Thanks in advance!

Alternative

No response

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.

[sapphi-red]

As you know, files that is not included in the exports field cannot be accessed via import. This is how Node.js works.

If package "a" accesses like that, package a is broken and it should be fixed on the package "a" side.
If package "b" added such an exports field in a minor or patch version, that is a error in that package. Because adding that is a breaking change.
If package "b" added it in a major version, then package "a" won't have a problem because package "a" would still be able to use the old version.

If you need to workaround it, you can patch the package "a"'s package.json to be:

  "exports": {
    "./*.js": "./*.js"
  }

You can also make a plugin for it if that's preferred.

I don't think Vite should allow non-standard things.

[EnixCoda]

Thanks for the fast reply and it is very inspirational!

If package "b" added it in a major version, then package "a" won't have a problem because package "a" would still be able to use the old version.

That’s exactly where the issue arises. Even if package “b” introduces the exports field in a major version, as long as package “b” doesn’t change its internal file structure, package “a”‘s outdated build tool won’t even notice. Since the tool doesn’t recognize the exports field, it unintentionally bypasses these new restrictions, making the breaking change effectively invisible to package “a”.

From this perspective, maybe it seems more like a design drawback of the exports field?

I'm totally fine with the decision of sticking with standard things only. I believe that is one important reason of Vite's success today.

[sapphi-red]

If package "b" added it in a major version, then package "a" won't have a problem because package "a" would still be able to use the old version.

That’s exactly where the issue arises. Even if package “b” introduces the exports field in a major version, as long as package “b” doesn’t change its internal file structure, package “a”‘s outdated build tool won’t even notice. Since the tool doesn’t recognize the exports field, it unintentionally bypasses these new restrictions, making the breaking change effectively invisible to package “a”.

In this case, I'd say it's a bug in package "a". package "a" should not rely on non-standard behavior and should revert / pin the version of package "b".

But yeah, I think it's a design drawback of the exports field.