@modusoperandi/eslint-config NPM

Modus Operandi eslint-config

Description

This package contains the core coding standards for all MO apps.

Requirements

Before you can start using the eslint-config your application must have the following dev-dependencies associated with your apps version of Angular:

eslint

Installation & Setup

Note for Angular projects. angular-eslint v18 is compatible with Angular v17 (required for using ESLint 9 on an Angular 17 project) as long as all angular-eslint packages are v18.

Run npm i -D @modusoperandi/eslint-config to install the package as a dev dependency. If using Angular, follow the Angular instructions to enable Linting with ESLint.
1. Remove all eslint dependencies aside from eslint and angular-lint from your dev-dependencies.
Copy the .eslint.config.js from this repo to the root of your project.
Change mo to the prefix of your Angular app/lib, or set to null if this isn't an Angular project.
Run ng lint (Angular) or eslint (Basic) in a script to ensure functionality. Add --max-warnings=0 to make these rules strict, or --quite to ignore warnings.

Optional

Add the .gitattributes from this project to your project to prevent End Of Line (EOL) issues in your repo.
If you are using VSCode, Make sure you have the following extensions that help with these rules.

Migrating from v1

Do steps 2 + 3 from the setup.
Change 'mo' in the config file to the prefix you are using for your Angular app/lib if necessary. The prefix overrides are part of the shared config.
If you have any rule overrides aside from the 2 Angular prefix rules, add them as shown here in accordence with the new ESLint flat config.
Delete your old eslint config file.

Usage Notes

console.log(...) should be avoided. These are usually forgotten debug statements, and when they’re not, their overuse can spam the logs hiding actual errors. It is recommended to use ngx-logger instead so that logging behavior can be controlled at the app layer. console.warn(...) and console.error(...) are ok to use though if necessary.
Mocking libraries are designed to be typescript friendly. If a mock library ever returns "any" as a type, that usually means you forgot to specify a type somewhere.
() => {} is commonly used for a "noop" function. However, {} looks like an empty object, and semantically empty function blocks are usually an unintended bug. use () => undefined instead to make the noop clear.
import/no-extraneous-dependencies means you're importing something that isn't declared in your package.json, and my not get installed if your dependencies of dependencies change. These packages need to be added to your peerDependencies or dependencies to protect you and your consumers.
The set of import rules that restrict absolute paths, cycles, and useless path segments are there to protect your code base from a variety of edge cases that can cause compile/runtime issues for you or your consumers.
"http://" can always be avoided. For URLs, you should always default to "https". For URIs like xml schemes, you should use an imported constant or parameter instead to avoid typo issues.