What non-standard linting rules might be useful for an Angular project?

For an Angular project, non-standard linting rules that help maintain architectural purity and improve code quality are useful:

• Prohibit the use of any — helps avoid loss of typing and runtime errors.

• Limit the depth of component and template nesting — prevents complex and hard-to-maintain structures.

• Naming rules for files and classes — for example, ensuring components, services, modules have consistent suffixes (.component.ts, .service.ts, etc.).

• Prohibit the use of console.log and other debug calls — to avoid leaving them in production code.

• Check proper use of the async pipe in templates — to prevent memory leaks and incorrect data updates.

• Limit the use of any in templates — to maintain type safety.

• Module import rules — for example, banning imports from deeply nested paths to preserve module encapsulation.

• Check for OnDestroy implementation and unsubscription from subscriptions — to prevent memory leaks.

These rules can be implemented using ESLint with Angular plugins, such as @angular-eslint, and custom rules.