deno publish: linter detect slow types on non-public API if `keyof typeof` is used on unexported member about deno HOT 4 CLOSED

Once a symbol is used in the public api (in this case QrCode), then the entire symbol and therefore all its dependencies become part of the public api for type checking and documentation. It would be quiet complex (especially for documentation) and slower to make a more targeted approach like this.

In this scenario, I'd recommend extracting out the ERROR_CORRECTION_LEVEL to a separate declaration that can be shared by the private QrCode class and the public API (which the extracted declaration is now part of)

from deno.

But shouldn't the linter check whether the symbol is actually exported ?

Because I'd understand if the keyof typeof itself would be considered a slow type, but in this case it seems to be able to correctly infer the typing so it doesn't make sense that it makes extra effort to check the remaining of an unexported symbol...

I've rewritten my code anyways, but still feels like a bug. It should either work or just forbids the usage of unexported members in "implicitely public" api because it seems kind of unpredictable whether the slow type is going to be triggered or not

from deno.

But shouldn't the linter check whether the symbol is actually exported ?

No, it's extremely common for people to write typescript code using symbols that aren't exported, but are part of the public api.

It doesn't identify exported symbols, but symbols that are part of the public API.

because it seems kind of unpredictable whether the slow type is going to be triggered or not

Essentially it examines the exported types and then their dependencies and their dependencies, etc. So any symbol that is used even transitively by an exported type is part of the public API.

from deno.

Ok thank a lot for the explanations, make sense

from deno.