@typescript-eslint errors in `i18n.ts`

[hb20007]

Description

1. I added next-intl to a boilerplate TS next project by following the documentation and the official example.
2. I added typescript-eslint for ESLint TypeScript support. by following the instructions here.
3. Finally, I enabled typed linting.

Upon running npx eslint ., I get the following errors for my i18n.ts file:

9:25 error Unsafe argument of type any assigned to a parameter of type string @typescript-eslint/no-unsafe-argument
9:35 error Unexpected any. Specify a different type @typescript-eslint/no-explicit-any
12:5 error Unsafe assignment of an any value @typescript-eslint/no-unsafe-assignment
12:60 error Unsafe member access .default on an any value @typescript-eslint/no-unsafe-member-access

i18n.ts:

import localeInfo from '@/localeInfo';
import { getRequestConfig } from 'next-intl/server';
import { notFound } from 'next/navigation';

const { locales } = localeInfo;

export default getRequestConfig(async ({ locale }) => {
  // Validate that the incoming `locale` parameter is valid
  if (!locales.includes(locale as any)) notFound();

  return {
    messages: (await import(`../messages/${locale}.json`)).default,
  };
});

I also found a discussion where another developer has reported the same issue: #445

Btw, in case I disable type-checked linting for the specific file, there is still an error, which is for the explicit any:

9:35 error Unexpected any. Specify a different type @typescript-eslint/no-explicit-any

Mandatory reproduction URL

https://github.com/amannn/next-intl/tree/main/examples/example-app-router

Reproduction description

1. Follow what I wrote in the "Description" section. Make sure that you have enabled typescript-eslint's linting with type information feature.
2. Run npx eslint .

Expected behaviour

There should be no errors and the documentation should not contain code which uses implicit or explicit any types.

[amannn]

To address the two lines reported by your linter:

1. Narrowing with .includes is something that's unfortunately not supported in TypeScript (microsoft/TypeScript#36275). If you want to comply with that lint rule, you can use one of the proposed workarounds in that thread or similar ones.
2. The dynamic import can't really be typed in a meaningful way here, but if you like, you can add your own runtime validation on top. However, next-intl includes a lot of error-handling capabilities that help with catching errors in messages.

Generally, the code presented works fine without any issues. If you choose to enable lint rules that find theoretical issues in code, I'm afraid it's your job to find patterns that align with your rules.

Sorry for pushing a bit back here, but next-intl has to operate in the spectrum of integrating deeply with tools like React and Next.js, while also working well with TypeScript. The code that's reported by your linter here doesn't have any issues, therefore I'd question if you really want those rules or if you want to disable them here. next-intl tries to integrate with TypeScript in any way where actual issues can be discovered (e.g. a type-safe t function), but the snippet you've pasted above just isn't an issue.

I'm closing this issue therefore, I hope you can understand.