Port DataLoader to TypeScript

[NShahri]

This PR migrates the entire codebase from JavaScript/Flow to TypeScript, modernizing the stack and improving type safety, tooling, and maintainability.

✅ Changes Included

• Migrated all source and test files from .js to .ts
• Removed Flow types and replaced them with TypeScript equivalents
• Added tsconfig.json with strict compiler options
• Switched build system from Babel to tsup
• Support ESM
• Refactored tests to TypeScript with proper type annotations
• Updated package.json scripts and dependencies
• Upgrade Eslint config
• Removed obsolete files
• switch to npm

📈 Benefits
This migration lays the foundation for better maintainability, improved tooling support, and enhanced type safety.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: NShahri / name: Nima Shahri (05c662a, 509a351, 6374f4a, 910c937, a454ec2, b0814f9, b73bb0b, ed9862a, fab2884, faf3fb0, 028d3c9, 6da3bbb, 9fc234f, ca45b68)

[NShahri]

Hello, @leebyron @saihaj @graphql/dataloader-maintainers. This PR completes a full migration to TypeScript and includes several improvements to the build and test setup. I'd appreciate your review and any suggestions you might have. Thank you!

[jgcmarins]

Amazing

[ardatan]

CI seems failing. Could you take a look?

[NShahri]

Thanks @ardatan — I’ve fixed the CI issue. Could you please try re-running the workflow when you get a chance?

[ardatan]

@NShahri Still failing :/

[benjie]

FAIL src/__tests__/unhandled.test.ts
  ● Unhandled rejections › Not catching a primed error is an unhandled rejection

    TypeError: global._onUnhandledRejection is not a function

I think the issue is that this needs to be done in a "jest environment" rather than in the config file; the jest workers don't run with this (unless you have jest -i maybe?) IIRC.

[NShahri]

Hi @benjie @ardatan

• Unfortunately, it wasn’t possible to add unhandledRejection handler in Jest, even when using custom Jest environments. Because of this limitation, I decided to switch to Vitest.
• Additionally, I realized mocking global dependencies like process or setTimeout was difficult since they were required at module import time. To make mocking easier, I refactored the code so that these dependencies are accessed only when the DataLoader is initialized.

Please check the commit and let me know your thoughts.

[ardatan]

Still failing unfortunately.

[NShahri]

• Handling unhandledRejection in jest seems quite tricky— based on my research, it’s nearly impossible to do reliably. The only workaround I found is this approach, but it’s not ideal and feels a bit hacky.
• On the other hand, vitest does support handling unhandledRejection, but it requires NodeJs 20+, which might limit compatibility.
• Please correct me if I’m mistaken, but it looks like unhandled.test.ts is testing NodeJs behavior rather than application logic. I'm still unsure about the value of testing what happens when a rejected promise isn’t handled by user code. If that’s the case, perhaps this test could be removed or skipped?
• Also worth noting: there’s already a test that checks whether the priming error returns a rejected promise, which might be sufficient.

Would it make sense to remove or skip the unhandled.test.ts? Or is there a specific scenario we’re trying to safeguard against that I might be missing?