> It helps avoiding number of arguments problems, though

This issue is all about the number of arguments problem, and TypeScript (in cases like this) won't flag that problem. Which is something I think it should.

If you manually unroll the "map" and call parseInt() explicitly with the same arguments that map() calls parseInt() with, TypeScript will flag that. But not when map() is in the picture.

I understand why they chose to do that, but I still disagree with it.

he he I tried to fix this in Typescript but look like they do not care So I made and use (for my projects) my own version of typescript ;-) https://www.npmjs.com/package/@topce/typescript/v/5.1.6 There indeed you would have compile time error

error TS2345: Argument of type '(string: string, radix?: number) => number' is not assignable to parameter of type '(value: string, index: number, array: string[]) => number'. Target signature provides too few arguments. Expected 3 , but got 2.

console.log(["1","2","3"].map(parseInt));

This is great - I will definitely check this out.

I'm curious - have you been using this for long? Have you noticed any code which this flagged and which you thought it was being too strict? I feel like I would want this flag on all of the time, but I'm curious if there are edge cases that I have not considered but maybe you have experienced.

Not for a long just few days. It could be too strict , probably that why they rejected PR , but it depends of callback definition. I proposed it as a flag because it is breaking change by default turn it off. But as they rejected PR in my fork I remove flag and in latest version is always on.No flag. I change one my repo to use it and need to patch some lib definition of callback to be more strict also build with typescript "skipLibCheck": true,

If I do not want to change existing code to add parameters for each callback I use trick bellow : type JavaScriptCallback< T extends (...args: any) => any, P = Parameters<T> > = P extends [...infer Rest, infer _Last] ? ((...args: Rest) => ReturnType<T>) | JavaScriptCallback<T, Rest> : T;

interface Array<T> { forEach( callbackfn: JavaScriptCallback<(value: T, index: number, array: T[]) => void>, thisArg?: any ): void;

  map<U>(
    callbackfn: JavaScriptCallback<(value: T, index: number, array: T[]) => U>,
    thisArg?: any
  ): U[];

} and then is more like standard TypeScript would not complain about parseInt because I redefined typedef of map to accept 0 or 1 or 2 or 3 parameters . But I am in control. Only edge cases in some callbacks I notice tsc complains that type is any with strict option turn on then I add a type . It is experimental, would prefer if they add it as option. Change is just in checker emitted JavaScript is still same. As always there are some trades of. But for me it works so far so good ;-)

Thanks for the details!

No problem so basically you can fix errors : add parameters with that are not used for example _index, _array or override callback type definition wrap it in JavascriptCallback