prefer-reduce-type-parameter
Enforce using type parameter when calling
Array#reduce
instead of casting.
Extending "plugin:@typescript-eslint/strict-type-checked"
in an ESLint configuration enables this rule.
Some problems reported by this rule are automatically fixable by the --fix
ESLint command line option.
This rule requires type information to run.
It's common to call Array#reduce
with a generic type, such as an array or object, as the initial value.
Since these values are empty, their types are not usable:
[]
has typenever[]
, which can't have items pushed into it as nothing is typenever
{}
has type{}
, which doesn't have an index signature and so can't have properties added to it
A common solution to this problem is to use an as
assertion on the initial value.
While this will work, it's not the most optimal solution as type assertions have subtle effects on the underlying types that can allow bugs to slip in.
A better solution is to pass the type in as a generic type argument to Array#reduce
explicitly.
This means that TypeScript doesn't have to try to infer the type, and avoids the common pitfalls that come with casting.
This rule looks for calls to Array#reduce
, and reports if an initial value is being passed & asserted.
It will suggest instead pass the asserted type to Array#reduce
as a generic type argument.
module.exports = {
"rules": {
"@typescript-eslint/prefer-reduce-type-parameter": "error"
}
};
Try this rule in the playground ↗
Examples
- ❌ Incorrect
- ✅ Correct
[1, 2, 3].reduce((arr, num) => arr.concat(num * 2), [] as number[]);
['a', 'b'].reduce(
(accum, name) => ({
...accum,
[name]: true,
}),
{} as Record<string, boolean>,
);
Open in Playground[1, 2, 3].reduce<number[]>((arr, num) => arr.concat(num * 2), []);
['a', 'b'].reduce<Record<string, boolean>>(
(accum, name) => ({
...accum,
[name]: true,
}),
{},
);
Open in PlaygroundOptions
This rule is not configurable.
When Not To Use It
This rule can sometimes be difficult to work around when creating objects using a .reduce
.
See [prefer-reduce-type-parameter] unfixable reporting #3440 for more details.
You might consider using ESLint disable comments for those specific situations instead of completely disabling this rule.
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
See Troubleshooting > Linting with Type Information > Performance if you experience performance degredations after enabling type checked rules.