Many of these are arguable as the hinting system from typescript in modern editors (vs code, jetbrains, etc.) are able to determine return types, just as an example. Of course this can be argued of linting generally speaking, so it's okay as options.
My biggest niggle with TS lately, is that tsc and deno have different import rules... for deno, you must use the extension, for tsc you must not, and I really wish tsc could be changed via an option to match the deno behavior, which I feel is more correct. I think being able to share modules between the node/esbuild ecosystem and deno is going to become ever more important in the next couple years... especially if you can just share the ts source directly instead of built js modules with separate definitions.
In the final example about strictBindCallApply, the "solution" is presented as:
const numHandler = (a: number) => {
console.log(`log ${a}!`)
}
numHandler.call(undefined, '25')
This will trigger the same warning from tsc, because the 25 has been enclosed in quotes making it, still, a string.
(Also, all the code in that last section is missing the > in the =>)
P.S. The server at blog.openreplay.com seems to go down frequently.
In the final example about strictBindCallApply, the "solution" is presented as: const numHandler = (a: number) => { console.log(`log ${a}!`) } numHandler.call(undefined, '25') This will trigger the same warning from tsc, because the 25 has been enclosed in quotes making it, still, a string. (Also, all the code in that last section is missing the > in the =>) P.S. The server at blog.openreplay.com seems to go down frequently.