duplicate-export false positive for type/value merging

[cloud-walker]

When using Zod (or similar libraries), it's idiomatic TypeScript to export both a runtime validator and its inferred type under the same name:

export const Status = z.enum(['active', 'inactive'])
export type Status = z.infer<typeof Status>

TypeScript allows this because const and type live in separate namespaces — this is intentional declaration merging, not a mistake. The same pattern appears with Prisma generated types, class + interface merging, etc.

Fallow currently flags this as duplicate-export, which is a false positive. The two exports are not duplicates — one is a runtime value, the other is a compile-time type.

Expected behavior: fallow should recognise that a const/function/class export and a type export sharing the same name are distinct, and not flag the pair as a duplicate.

Current workaround: // fallow-ignore-file duplicate-export at the top of the affected file, but this suppresses the rule entirely rather than targeting the specific pattern.

Is this something fallow could detect and allow?

[BartWaardenburg]

Good catch! This is fixed in 6f461b6 (will ship in the next release).

The duplicate-export detection now tracks whether each export is type-only. Groups that mix value and type exports (like export const Status + export type Status) are recognized as TypeScript declaration merging and skipped. This covers Zod, Prisma, class+interface patterns, and any other value/type namespace split.

Same-namespace duplicates (two value exports or two type exports with the same name across files) are still correctly flagged.