Skip to content

Do not union any in Translation #1534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Ghostbird opened this issue Mar 19, 2025 · 3 comments
Open

Do not union any in Translation #1534

Ghostbird opened this issue Mar 19, 2025 · 3 comments

Comments

@Ghostbird
Copy link

Ghostbird commented Mar 19, 2025

According to the lines below, the any union is necessary.

export type Translation =
string |
Translation[] |
TranslationObject |
// required to prevent error "Type instantiation is excessively deep and possibly infinite."
// eslint-disable-next-line @typescript-eslint/no-explicit-any
any

However, this causes me issues, since the type of Translation is any because any overrides everything.
So I tried this in my local repo ("typescript": "^5.4.5") and I get no such recursion message.

// eslint-disable-next-line @typescript-eslint/consistent-indexed-object-style
interface TranslationObject {
  [key: string]: Translation;
}
type Translation = string | Translation[] | TranslationObject;

I can think of two possible causes (but there might be another reason):

  • When this code was written, that restriction was in place, but it was removed in a later Typescript version.
  • When this code was written, the restriction was detected, and circumvented by making TranslationObject an interface. However the | any was not removed by accident.

Can this | any be removed?

@CodeAndWeb
Copy link
Member

Interesting.

Did you try to run the lint job?

@Ghostbird
Copy link
Author

That's referenced in my second point:

When this code was written, the restriction was detected, and circumvented by making TranslationObject an interface.

The restriction can be circumvented by writing TranslationObject as an interface instead of a type assignment. However that requires // eslint-disable-next-line @typescript-eslint/consistent-indexed-object-style to be set to allow an interface to be used where a type assignment would have been more concise.

If you remove that comment, the linting fails.

@SvajkaJ
Copy link

SvajkaJ commented Apr 2, 2025

I also kindly ask for this improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants