package.json `exports` resolution uses fallback conditions, unlike Node

Bug Report

🔎 Search Terms

I’ve never been more confident, without searching, that I’m the first person to notice this

💻 Code

{
  "exports": {
    ".": {
      "import": "./dist/main.mjs",
      "types": "./dist/foo.d.ts"
    }
  }
}

🙁 Actual behavior

Importing this package from an ESM file, in --moduleResolution nodenext, searches for types at these locations:

• ./dist/main.mts
• ./dist/main.d.mts
• ./dist/foo.d.ts

🙂 Expected behavior

It should not search the types condition, because import already matched, and contained a valid target ./dist/main.mjs. Resolution here should fail for consistency with Node, which would throw a resolution error if it matched a condition but then failed to find the file specified in it.

Fixing this bug may cause more harm than good. I noticed it because I claimed that a popular library would be broken under certain conditions due to misconfigured exports, but was proven wrong in reality. I figured this may be worth documenting, but likely not worth fixing. But if someone can make a good case for why it matters, I would reconsider.

[Andarist]

@hayes I was just working around this exact issue earlier today. You can check out what we have settled on at the end in this PR: https://github.com/alexreardon/tiny-invariant/pull/150/files

With the types condition being used first it’s implied that this package is treated as a CJS package (it has no package.json#type set). And importing default export from a CJS package doesn’t work in node - it returns the namespace object instead of the default export.

[andrewbranch]

That’s correct; https://github.com/hayes/ts-esm-cjs-nodenext is unrelated to this issue.