Ignore export (e.g. for declarations)

[OliverJAsh]

When using TypeScript’s declaration compiler option, TypeScript will complain when a non-exported value/type is used by an exported value/type, for example:

src/helpers.ts(67,45): error TS4081: Exported type alias 'validateType' has or is using private name 'Either'.

This means that the item must be exported, but then ts-unused-exports will complain that it is unused, when in fact it is needed by the declaration option to correctly create the declaration files.

Perhaps we could add an option to mark an export as ignored, like you can for disabling linters like TSLint/ESLint?

[pzavolinsky]

Hi @OliverJAsh, makes sense.

Ideally I'd love to leave the original code untouched.

But maybe we could stop complaining about exported types when declaration is set.

The optimal solution would be:

If an exported type is being used by another exported symbol (function, const, class, etc.), then don't complain about it

But I suspect it will considerably harder to implement, so I'm leaning more towards:

If delcaration is set, unused exported types will not be reported as errors

What do you think?

[OliverJAsh]

If delcaration is set, unused exported types will not be reported as errors

Hmm, this would render the tool unusable for projects that use the declaration option. I would prefer an option to selectively disable the tool, however I appreciate you want to learn the code untouched.

Perhaps we should wait and see if other people want this feature, or another use case comes up? :-)

For now, I am happy to just use the tool manually and mentally ignore the ones I know are safe.

[Bnaya]

It will be very nice to be able adding specific annotation in comment to tell the tool to ignore the export. like // @external-api or so

[mrseanryan]

You can now use comment flags to ignore exports:

// ts-unused-exports:disable-next-line
export function add2(x:number) { return x + 2; }

Perhaps that is good enough to handle this issue?

[mrseanryan]

Closing (seems to be covered with comment feature)

[trusktr]

I've opened a request to fix issues like these in TypeScript by bringing declaration files to parity with language features. https://github.com/microsoft/TypeScript/issues/35822