fix(defu.d.cts): export Defu types

[J-Michalek]

407b516#r181346453

[coderabbitai]

📝 Walkthrough

Walkthrough

The TypeScript definition file lib/defu.d.cts now re-exports three types (Defu, DefuFn, DefuInstance) alongside the existing CommonJS export, making these types directly accessible from this file.

Changes

Cohort / File(s)	Summary
Type Re-exports lib/defu.d.cts	Added export type { Defu, DefuFn, DefuInstance } to re-export TypeScript types directly from this declaration file alongside the existing CommonJS export.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 Types now hop freely from the declaration's door,
Three friends (Defu, DefuFn, DefuInstance) exposed once more,
No logic changed, just API's gentle bloom,
Making imports easier from the consumer's room! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'fix(defu.d.cts): export Defu types' directly and concisely describes the main change—adding type re-exports to the defu.d.cts file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@lib/defu.d.cts`:
- Around line 13-14: Remove the top-level `export type { Defu, DefuFn,
DefuInstance }` and replace it by declaring a namespace named `defuProxy` that
re-exports the types (`Defu`, `DefuFn`, `DefuInstance`) inside it, then use
`export = defuProxy` as the module export; locate the current `export type`
statement and the `defuProxy`/`defu` declarations and move the type definitions
into `declare namespace defuProxy { export type Defu = ...; export type DefuFn =
...; export type DefuInstance = ... }` so the module uses the
CommonJS-compatible `export = defuProxy` mechanism.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 7cde49bd-828b-45e9-b2b4-c90a1cec5a3d

📥 Commits

Reviewing files that changed from the base of the PR and between 001c290 and 17114f9.

📒 Files selected for processing (1)

• lib/defu.d.cts

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In the TypeScript version used by this project, is export = fooallowed in the same.d.ctsfile asexport type { A, B }? If not, what is the recommended pattern to expose additional types from a CommonJS declaration module?

💡 Result:

No, export = foo is not allowed in the same .d.cts file as export type { A, B }. .d.cts files are treated as CommonJS declaration modules, where the primary export must use the CommonJS-style export = syntax for the module.exports value, and ES module-style named exports like export type are incompatible in the same file because they represent different module systems. The recommended pattern to expose additional types from a CommonJS declaration module (including .d.cts) is to declare them within a namespace attached to the main exported value, or use top-level ES module-style export type only if not mixing with export =. For export = foo specifically: declare type A = ...; declare type B = ...; declare const foo: FooType & { A: A; B: B }; // or namespace export = foo; Or more commonly for functions/classes with properties: declare function foo: void; declare namespace foo { export type A = ...; export type B = ...; } export = foo; This mirrors official patterns from TypeScript documentation for CommonJS modules. For Node16/nodenext with .d.cts, the same CommonJS declaration rules apply as .d.ts for require conditions, using export = for the exports object and namespaces for additional members/types.

Citations:

• 1: https://www.typescriptlang.org/docs/handbook/declaration-files/templates/module-d-ts.html
• 2: https://typescriptlang.org/docs/handbook/declaration-files/templates/module-d-ts.html
• 3: Types in d.cts is incorrect when the entry has multiple exports unbuild#531
• 4: should allow use export = in .cts when module is esnext microsoft/TypeScript#51018
• 5: https://zenn.dev/uhyo/articles/typescript-module-option?locale=en

---

Remove export type statement; incompatible with export = in CommonJS declaration files

In .d.cts files, export = defuProxy and export type { ... } cannot coexist. TypeScript treats .d.cts as CommonJS declaration modules where export = is the sole export mechanism. Expose these types via a namespace instead:

declare namespace defuProxy {
  export type Defu = ...
  export type DefuFn = ...
  export type DefuInstance = ...
}
export = defuProxy

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@lib/defu.d.cts` around lines 13 - 14, Remove the top-level `export type {
Defu, DefuFn, DefuInstance }` and replace it by declaring a namespace named
`defuProxy` that re-exports the types (`Defu`, `DefuFn`, `DefuInstance`) inside
it, then use `export = defuProxy` as the module export; locate the current
`export type` statement and the `defuProxy`/`defu` declarations and move the
type definitions into `declare namespace defuProxy { export type Defu = ...;
export type DefuFn = ...; export type DefuInstance = ... }` so the module uses
the CommonJS-compatible `export = defuProxy` mechanism.