Shared TSLint & codelyzer rules to enforce a consistent code style for Angular development
Please support this project by simply putting a Github star. Share this library with friends on Twitter and everywhere else you can.
The value of the software produced is directly affected by the quality of the codebase, and not every developer might
- be aware of the potential pitfalls of certain constructions in TypeScript,
- be introduced into certain conventions when using the Angular framework,
- know that not every developer is as capable in understanding an elegant (but abstract) solution as the original developer.
For that purpose, we need to use static code analysis tools such as TSLint and codelyzer to check readability, maintainability, and functionality errors.
Although complying with these tools may seem to appear as undesired overhead or may limit creativity, it becomes easier for any new developers to read, preventing a lot of time/frustration spent figuring out the structure and characteristics of the code.
Containing a set of TSLint and codelyzer rules, angular-tslint-rules has been compiled using many contributions
from colleagues, commercial/open-source projects and some other sources from the Internet, as well as years of development
using the Angular framework.
All TSLint rules covered by this project are explained on this article https://medium.com/burak-tasci/angular-tslint-rules-a-configuration-preset-for-both-tslint-codelyzer-8b5fa1455908, in depth.
If you have questions, comments or suggestions, just create an issue on this repository. I'll try to revise and republish these rules with new insights, experiences and remarks in alignment with the updates on TSLint and codelyzer.
If you want to file a bug, contribute some code, or improve documentation, please read up on the following contribution guidelines:
The MIT License (MIT)
Copyright (c) 2019 Burak Tasci