Nested export *s cause false positives for unused export detection

[JoshuaKGoldberg]

Coming over from JoshuaKGoldberg/ts-api-utils#33 (comment): it looks like the following chain is causing some false positives:

• ./src/index.ts: export * from "./nodes/typeGuards/index.js"
• ./src/nodes/typeGuards/index.ts: export * from "./compound" (with or without a .js extension)
• ./src/nodes/typeGuards/compound.ts: some exported functions

...with the following knip.jsonc:

{
	"entry": "src/index.ts!",
	"project": "src/**/*.ts!"
}

git clone /~https://github.com/JoshuaKGoldberg/ts-api-utils
cd ts-api-utils
git checkout 3059705
pnpm install
pnpm run lint:knip

 $ pnpm lint:knip

> ts-api-utils@0.0.20 lint:knip /Users/josh/repos/ts-api-utils
> knip

Unused exports in namespaces (83)
isAssignmentExpression                     src/nodes/typeGuards/compound.ts
isIterationStatement                       src/nodes/typeGuards/compound.ts
...
Unused exported types in namespaces (3)
ConstAssertionExpression    type  src/nodes/typeGuards/compound.ts
ConstAssertionIdentifier    type  src/nodes/typeGuards/compound.ts
NumericOrStringLikeLiteral  type  src/nodes/typeGuards/compound.ts

cc @RebeccaStevens

[webpro]

This is by design. The values and types are re-exported through a namespace, and not used, so they're flagged as "unused exports/types in namespaces".

Also see /~https://github.com/webpro/knip#too-many-unused-exports for possible ways to go about this.

I'm interested to better understand why this is unexpected behavior and/or how to make it easier to deal with.

[JoshuaKGoldberg]

why this is unexpected behavior and/or how to make it easier to deal with

Yeah this was surprising to me, and I didn't connect that the Too many unused exports section connected to it.

The package is a utility library exported a collection of functions and types to be used by consumers. We use export * from nested namespaces so that we can have multiple files/folders all exported through the root index.ts.

Let's say the package originally had one index.ts file...

// index.ts
export const apple = "apple";
export const banana = "banana";

...then we added a second file, so the index.ts was used to export everything from both files...

// index.ts
export * from fruits from "./fruits.js";
export * from vegetables from "./vegetables.js";

// fruits.ts
export const apple = "apple";
export const banana = "banana";

// vegetables.ts
export const yam = "yam";
export const zucchini = "zucchini";

...then one of those two files had a lot in them, so we split them up into nested files - with everything exported through a nested index.ts that is itself exported through the index.ts...

// index.ts
export * from fruits from "./fruits/index.js";
export * from vegetables from "./vegetables.js";

// fruits/index.ts
export * from a from "./a.js";
export * from b from "./b.js";

// fruits/a.ts
export const apple = "apple";
export const apricot = "apricot";

// fruits/b.ts
export const banana = "banana";
export const blackberry = "blackberry";

// vegetables.ts
export const yam = "yam";
export const zucchini = "zucchini";

From our perspective, the fact that exported items are in the root index.ts vs. a nested index.ts vs a nested-nested file is irrelevant. They're all things exported through the root index.ts.

Does that make sense?

[webpro]

Yes, that makes sense! I think the question here is whether Knip should ignore re-exports cq the files it re-exports from entry files (like in your example). And at this point I'm positive, I'll give it another thought and look into it shortly.

[webpro]

Quick update. The upcoming v2 is progressing pretty well, but the refactoring I'm working on is quite the undertaking. Major improvements in performance though, while also fixing bugs like this one reported.

[webpro]

Closing this as it should be fixed in v2 :)