Kirill Korolyov

I also get the same issue. However, trying to debug this made me realise that the problem doesn't lie with this library or even Chargebee itself, but with trying to...

Thanks for the explanation. What would be the downsides of generating a name? FYI [react-aria](https://react-spectrum.adobe.com/react-aria/RadioGroup.html) generates a name.

@IchordeDionysos You can also consider [eslint-plugin-no-type-assertion](https://www.npmjs.com/package/eslint-plugin-no-type-assertion) (disclaimer: I'm the author). It allows to keep using `as const` and `as unknown` assertions, since these are safe.

@bradzacher does this rule also exclude `as unknown` assertions? I'm happy to deprecate my plugin if its functionality can be fully covered by `typescript-eslint`.

What I meant is that `as unknown` assertions are actually safe to have, so they don't need to be banned.

> Most of the time. What about asserting a `never`-typed value to anything else, including `unknown`? I can't think of a scenario of how one would acquire a `never` value...

@JoshuaKGoldberg that's an interesting scenario. If the code under the `default` branch does run, it implies the type definition was incomplete. In this case, it is safe to assert `response.type`...

Not ideal, but passing `UNSTABLE_renderPolicy: 'full'` to the query options makes the error go away. Still an issue on 14.1.0. _Update_: in my case the error seems to be originating...

Have you considered adding them to [entry](https://knip.dev/reference/configuration#entry)? This is what we do for files that are not used **yet**.