chore(build): migrate to tsdown

[nakanoasaservice]

Summary

tsup is no longer actively maintained and recommends migrating to tsdown. This PR follows that recommendation and replaces tsup with tsdown, which is built on top of rolldown and provides better alignment with the Vite/rolldown ecosystem.

For easier review, I also added a link to the actual build output (generated artifacts), which you can inspect directly on GitHub here: https://github.com/nakanoasaservice/honox/pull/3/files

Changes

• Replace tsup.config.ts with tsdown.config.ts
• Update prepare, build, and watch scripts to use tsdown
• Auto-generate the exports field in package.json via tsdown's built-in exports: true option, removing the need to maintain it manually
• Remove non-existent utils/* entry from typesVersions

Critical fix: preserve import.meta.glob

tsdown enables globImport by default, which causes rolldown to resolve import.meta.glob() calls at library build time. Since /app/ does not exist in this repository, all globs would resolve to empty objects —silently breaking island hydration, auto-routing, and manifest loading for every consumer.

Setting globImport: false preserves the expressions as-is so that the consumer's Vite build can process them correctly, matching the behavior of the previous tsup/esbuild output.

Notes on output differences

The generated files have minor cosmetic differences compared to tsup (indentation style, #region comments, import ordering), but are functionally equivalent.

One observable difference is that the type modifier on re-exports in .d.ts files is inconsistently applied between tsup and tsdown — in some leaf files (e.g. client/client.d.ts) tsdown omits type from export { type ClientOptions }, while in index files it adds it where tsup did not. This has no practical impact: TypeScript infers type-only status from the original declaration (e.g. type ClientOptions = ...), so consumers with verbatimModuleSyntax: true are unaffected for any public import path.

Discussion: remove typesVersions?

typesVersions is kept as-is for backwards compatibility with older TypeScript versions that do not support the exports field for type resolution. However, since the exports field is now the source of truth (and is auto-generated), typesVersions must be kept in sync manually. Given that TypeScript 4.7+ (released 2022) supports exports-based type resolution, it may be worth dropping typesVersions entirely in a future change.

[yusukebe]

This will fix #360

[yusukebe]

This is actually unnecessary.

[yusukebe]

LGTM!

[yusukebe]

Hey @nakanoasaservice

Thank you for your polite PR. Looks good. I'll merge.