type-challenges VS typescript-eslint

View on GitHub

For those who want to improve their type level skills, I highly recommend this repository for learning by doing: https://github.com/type-challenges/type-challenges.

I'm very like typescript and I always try to learn something interesting there. I thought that it is impossible to know the length of the string in typescript, but I was wrong. Today during solving typescript challenge I found a way to do it. If you don't know about typescript challenges, you can read about it here, it is a very interesting project, and I highly recommend you to try it, if you, like me, obsessed with typescript.

For those wonder why you don’t need a CS degree, I invite you to solve the type problems here https://github.com/type-challenges/type-challenges. No degree needed and if you can solve those problems with ease (as really understand the problems), you can work on any problems in any business.

It's not really a major usage but I think it would be cool to see if a coding model could be fine-tuned to take in a prompt of instructions and output a valid Typescript type solution (like in https://github.com/type-challenges/type-challenges)

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

By convention, React components should be named in PascalCase. @typescript-eslint has the config we need, and though we can't specifically target React components, we can target variables (and set some other conventions while we're at it):