Package Exports resolution differs from Node in 2 edge cases about metro

[huntie]

Thanks @jbroma!

1. Root Array Shorthand

Wow, essentially these implementations have a special-case expansion of ["./index.js"] to {".": "./index.js"} — happy to align ✅.

2. Subpath Patterns in exports

Yup, also looks incorrect ✅. I don't think we have a test against that behaviour at all.

---

IMO, these test cases should be marked as [nonstrict] as they rely on fallback mechanism:

• should resolve "exports" target directly > without expanding sourceExts
• should resolve "exports" target directly > without expanding platform-specific extensions

These tests are for in-spec behaviour, so I think this is right as-is. However, the assertions seem slightly wrong (unless I'm misremembering) — they should be index-exports.js. This test needs a little fixing.

---

Yes please to PRs! 🙌🏻 Recommend splitting into one PR per fix, and we'll happily look through :).

[jbroma]

@huntie all tasks from the issue handled in the PRs above.

[jbroma]

Few other insights about Package Exports implementation & tests:

1. When multiple entires in root array shorthand are defined the resolvers behave in a following way:

   • node: looks for first valid specifier (beginning with ./), and returns it, even when it's non-existent
   • enhanced-resolve: similar to node, but looks for first valid entry that actually exists
   • metro-resolver: can't tell because case from the issue fails

2. IMO, these test cases should be marked as [nonstrict] as they rely on fallback mechanism:

• should resolve "exports" target directly > without expanding sourceExts
• should resolve "exports" target directly > without expanding platform-specific extensions

FYI, im willing to submit a PR for this after we agree on the spec.