Fix: move types condition to the front

[Andarist]

I moved types condition to the front. package.json#exports are order-sensitive - they are always matched from the top to the bottom. When a match is found then it should be used and no further matching should occur.

Right now, the current setup works in TypeScript but it's considered a bug and it should not be relied upon, see the thread and the comment here. For that reason, I would like to fix all popular packages that misconfigured their exports this way so the bug can be fixed in TypeScript.

⚠️ this PR focuses solely on fixing "🐛 Used fallback condition" problem but the "🎭 Masquerading as CJS" remains here. You can check the reported errors here

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
discord-api-types	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 30, 2023 10:14pm

[vladfrangu]

I understand that this is supposed to fix the linked issue, but doesn't this actually break esm imports now? We only generate cjs output via tsc, and an esm wrapper that re-exports from cjs, which doesn't have its own types 👀

[vladfrangu]

Disregard, turns out I'm blind, the types line has been moved to be first in the object (although I fail to see how that matters since objects don't necessarily have an order) 🫥

[kyranet]

It does if you use Object.entries, as object entries are insert-size, or in this case, however they're ordered in the source.

[Andarist]

Disregard, turns out I'm blind, the types line has been moved to be first in the object (although I fail to see how that matters since objects don't necessarily have an order) 🫥

I can expand a little bit on what @kyranet mentioned. Since es2015 the keys in objects have defined order. It's an insertion order with the exception that number-like keys are at the beginning and those are sorted:

var foo = {}
foo.b = null
foo.a = null
foo[10] = null
foo[1] = null

Object.keys(foo) // ['1', '10', 'b', 'a']

This fact is leveraged by the defined algorithm for package.json#exports resolution. You can find it in this section: "PACKAGE_TARGET_RESOLVE(packageURL, target, patternMatch,
isImports, conditions)":

2. For each property p of target, in object insertion order as,

[iCrawl]

@Andarist Do you know how this affects top-level keys? We do have some modules that basically just do this:

With no explicit exports field.

[Andarist]

Those are not order-sensitive. It's up to the bundler~ (and runtimes) to pick up the correct field. Note that most of those fields are overriden if exports are present (to the best of my knowledge only "alias" fields, such as package.json#browser, are still considered when resolving the file when exports are present). However, in TypeScript you must opt-into reading exports with the new moduleResolution: node16/nodenext - without that exports are ignored.

Does this clarify it for you? I can answer some extra questions if you have regarding this.

[iCrawl]

That answers all my questions, thank you!