- TypeScript, with or without Angular 2+
- React Native flavored JSX
- Others, too many to even mention
During project initiation, and as appropriate thereafter in the project lifecycle, engineers should choose a current and industry accepted set of rules that the project team agrees with. Teams may elect to make modifications to their rulesets by consensus at any time, but individual engineers on a larger team should not modify rules without team consensus.
Code must not be committed with any ESLint errors. Code should not be committed with ESLint warnings. Use ESLint ignore comments sparingly, and only with good reason.
The TypeScript compiler will, if in use, enforce additional criteria. Use of type annotations is recommended, particularly when code is subject to being passed between functions or between files. 100% annotation is not required.
Non-Enforceable Code and Good Taste
There are many aspects of good code that do not readily translate to specific rules, such as:
- Clear variable naming
- Architectural considerations
- Ease of understanding and maintenance
A passing ESLint config does not mean that code meets any of the above quality criteria. The pull request code review process is an excellent opportunity to get a second set of eyes on code, particularly to look for higher level quality issues.