Rules to Better TypeScript - 5 Rules
TypeScript’s any keyword is a blessing and a curse. It is a type that can be anything, where every possible property and method exists and also returns any. It can be casted to and from anything and is how you tell the compiler to get out of your way.
However, it’s easy to use it as a crutch, and as a result, miss out on handy intellisense, refactoring support and compile-time safety – the main benefits of TypeScript!
If you're trying to write more type-safe code, it's generally recommended to use "unknown" instead of "any" wherever possible, as it forces you to perform type checks and can help catch errors earlier in the development process.
If you have ESLint enabled in your project, you can enable the
no-explicit-anyrule to provide useful lint warnings or errors to ensure the
anytype is not used in the project.
This comes down to personal preference, but there are only a few times when you must define a type in TypeScript, for example:
- When initializing a variable with an ambiguous value (eg. null)
- Function parameters
Of course, there are also times when you may want to be more explicit – you may want to have an interface as a function return value instead of the class, for example.
The rest of the time, rely on TypeScript to infer the type for you.
Putting a “tsconfig.json” file in your project tells the typescript compiler where the root of your project is, and provides a centralized place to configure the compiler. This config is read by IDEs and the compiler and can be utilised by the build scripts to ensure configuration is consistent.
The primary benefit of TypeScript is type-safety, and attempting to escape from the type-safety should be a conscientious decision by the developer. So ensure that noImplicitAny is true, and keep your code type-aware and able to be refactored.
By default, the compiler will compile everything ending in .ts. This means things inside node_modules and even typings will be parsed and included. Ensure you exclude these files to reduce your compile time and, more importantly, reduce your reported errors.
TypeScript should compile in-place, and a single file input should produce a single file output. This reduces compile time, and puts bundling in the hands of a system that knows more about the modules – the module loader.
Files generated from typescript get in the way – you don’t want to scroll through .d.ts, .js and .js.map files all the time. So hide them in the IDE.In VSCode this can be done via the “files.exclude” key in the settings.json file. For a shared experience across the team, check this file into source control.
Each file in TypeScript is a module, and each module can export whatever members it wants. However, if you export everything, you run the risk of having to increment major versions (when using semantic versioning), or having your module used in unintended ways.
Only export the types necessary to reduce your API surface. Often, this means exporting interfaces over implementations.