The already-filed issue about eslint.config.mjs covers @typescript-eslint/no-floating-promises and @typescript-eslint/no-unsafe-argument being downgraded from the recommendedTypeChecked preset's error to warn. The same rules block also sets '@typescript-eslint/no-explicit-any': 'off' — not just downgraded, fully disabled — for a codebase that otherwise leans on TypeScript's type system fairly heavily (strict-family tsconfig.json flags, class-validator-typed DTOs throughout). Disabling no-explicit-any entirely means an any typed value can flow through any function signature with zero lint signal, silently defeating the type-safety the rest of the configuration is trying to establish. Worth revisiting alongside the other two downgraded rules, even if the end decision is to keep it off deliberately (in which case a comment explaining why would help future contributors).
The already-filed issue about
eslint.config.mjscovers@typescript-eslint/no-floating-promisesand@typescript-eslint/no-unsafe-argumentbeing downgraded from therecommendedTypeCheckedpreset'serrortowarn. The same rules block also sets'@typescript-eslint/no-explicit-any': 'off'— not just downgraded, fully disabled — for a codebase that otherwise leans on TypeScript's type system fairly heavily (strict-familytsconfig.jsonflags,class-validator-typed DTOs throughout). Disablingno-explicit-anyentirely means ananytyped value can flow through any function signature with zero lint signal, silently defeating the type-safety the rest of the configuration is trying to establish. Worth revisiting alongside the other two downgraded rules, even if the end decision is to keep it off deliberately (in which case a comment explaining why would help future contributors).