[BUG] Many duplicated type files

[veksa]

Before you begin...

• I have searched the existing issues
• I am not using version 13.x of node (if so, please upgrade)

Description of the problem

After switching to building with tsc (#763), the resulting bundles contain many duplicate type files for each bundle type (CJS, ESM, etc.).

This can be resolved by generating types only once, instead of doing it for each bundle separately.

This can be achieved by building with tsup (https://github.com/egoist/tsup).

Recipe for reproducing

No response

Additional information

No response

Environment

No response

[broofa]

Other than increasing the package size (by ~400K), can you elaborate on what adverse impacts this has?

I'm open to ways to dedupe the type files but the current setup is simple and obvious, which tends to pay dividends when it comes to maintainability.

Regarding tsup, not having used it before it's not clear to me how it helps. For example, tsup src --format cjs,esm --dts --clean --sourcemap results in a dist directory that's 30% larger than what we have currently (1.9M vs 1.4M) ... and that doesn't include browser-specific builds.

If you'd like to put up a PR that shows how you'd solve this issue, I'd be curious to see what you have in mind.

[broofa]

Noting for posterity that there are a couple [very small] differences between the node vs browser types:

$ diff -r esm esm-browser
Only in esm: bin
diff -r esm/md5.d.ts esm-browser/md5.d.ts
1c1
< declare function md5(bytes: Uint8Array): Buffer;
---
> declare function md5(bytes: Uint8Array): Uint8Array;
diff -r esm/native.d.ts esm-browser/native.d.ts
1d0
< import { randomUUID } from 'crypto';
3c2
<     randomUUID: typeof randomUUID;
---
>     randomUUID: false | (() => `${string}-${string}-${string}-${string}-${string}`);
diff -r esm/sha1.d.ts esm-browser/sha1.d.ts
1c1
< declare function sha1(bytes: Uint8Array): Buffer;
---
> declare function sha1(bytes: Uint8Array): Uint8Array;

[broofa]

Closing because ...

1. No response from OP on adverse impacts
2. No simple solution to this.

While package.json#types is a thing, TS documents that as referencing the file pointed to by the package.json#main field. But this projects setup is more complicated than that. Specifically, it uses a fairly elaborate package.json#exports setup to point bundlers (and TS?) at the different dist/* builds depending on the context.

I'm not at all confident we'd be able to get this working without a lot of trial-and-error that basically uses this project's users as guinea pigs.