Kirk Waiblinger

> Sounds like a valuable thing yeah. Part of me thinks it might want an option for that rule though - I could see people using assertion functions to enforce...

TLDR - I don't think you want to use disable-type-checked for disabling typescript-eslint rules in `*.js` files. I would just disable all typescript-eslint rules. *** I guess it's a question...

> I don't think that's a good summary, no. Lol, savage 😅 But, after reading your response, I think you're right 😆 > Many of our rules work just fine...

And, fair enough, but wouldn't it more helpful to the user to achieve that goal having a doc section that looks (very very) roughly like *** ### Working with a...

also, lol on the eslint.config.js being the culprit 😆

I think I'm ok with that, too. After a little experimentation i think that's safe as far as passing the narrowed function, too, since ```ts declare const looselyTypedFunction: Function; //...

I guess the downside is just that I could see wanting `no-unsafe-call` disabled but still wanting the sneaky `Function` call safety

Also reported on SO: https://stackoverflow.com/questions/78342447/im-using-typescript-eslint-parser-to-parse-a-typescript-function-how-can-i-ge#78434221

+1 on calling out explicitly, and mentioning .mjs option.

It looks like the docs website doesn't have any accompanying changes to indicate the deprecation other than it showing in the deprecated column of the table... Consider adding a doc...