AbsoluteJS

absolute/no-redundant-type-annotation

Disallow type annotations on variable declarations whose initializer already has the same inferred type.

TypeScriptSuggestionFixableType-aware
View on GitHub

#Rule Details

A type-aware rule that removes a variable’s type annotation when the initializer already produces exactly that type, then autofixes by deleting the annotation. It only considers initializers whose inferred type is independent of context — calls, identifiers, member access, new expressions, and as casts — so it never strips an annotation that is doing widening work.

Several cases are deliberately preserved: a literal initializer (where : string widens "hello"), object/array literals (which are contextually typed), an annotation that references a type alias the initializer does not carry (the alias documents intent), and generics whose type parameter is steered by the annotation (like querySelector<E>), where removing it would change the result.

This rule requires type information. Set parserOptions.project to your tsconfig.json; without typed services it becomes a no-op.

#Examples

Incorrect
TS
function makeUser(): User { /* ... */ }
const user: User = makeUser();   // → const user = makeUser();

class Box {}
const box: Box = new Box();      // → const box = new Box();

declare const count: number;
const total: number = count;     // → const total = count;
Correct
TS
const greeting: string = 'hello'; // literal widening — annotation does work
const ids: string[] = [];          // array literal is not in the allow-list

type ID = string;
declare function loadId(): string;
const id: ID = loadId();           // the alias documents intent
TS
const el: HTMLInputElement | null = document.querySelector('input');
// the annotation steers the generic, so it is kept

#Configuration

Enable this rule in your ESLint configuration:

JS
// Requires typed linting
{
	languageOptions: {
		parserOptions: { project: './tsconfig.json' }
	},
	rules: {
		'absolute/no-redundant-type-annotation': 'warn'
	}
}

#When Not To Use It

If you cannot enable type-aware linting (no parserOptions.project), the rule does nothing. Teams that prefer explicit annotations as living documentation — even when redundant — should leave it off.

#Resources