Official Neo Financial ESLint configuration
This package includes 5 different ESLint configs:
config-backendconfig-frontendconfig-backend-nextconfig-frontend-nextconfig-architecture
The next versions include some rules that are being considered for inclusion in future versions of the base config. The next configs also require you to specify the project setting in parserOptions for TypeScript projects. The will make ESLint run slower in TypeScript projects.
The config-architecture is designed for services that have migrated to Biome.js for linting and formatting. It contains ONLY the hexagonal architecture enforcement rules that Biome cannot provide:
import/no-restricted-paths- Enforces layer boundaries (domain, application, infrastructure)@typescript-eslint/no-restricted-imports- Enforces lodash tree-shaking and domain isolation
Use this config alongside Biome to maintain architecture enforcement while benefiting from Biome's speed.
flowchart LR
A[config-base]
B[config-base-next]
C[config-backend]
D[config-frontend]
E[config-backend-next]
F[config-frontend-next]
G[config-architecture]
A --> C
G --> C
A --> D
A --> B
B --> E
B --> F
The arrows from left to right illustrate which configs are extended by another config.
config-backendextends bothconfig-baseandconfig-architectureconfig-architectureis also available standalone for Biome users who only need hexagonal architecture enforcement
npm install --save-dev eslint-config-neo
You can also install a specific version of the package by appending the version tag. For example, to install version 1.0.0
npm install --save-dev eslint-config-neo@1.0.0
npm install -D eslint prettier lint-staged husky typescriptAdd .eslintrc to project root
{
"extends": "eslint-config-neo/config-backend"
}Use eslint-config-neo/config-frontend for frontend projects
If you're using one of the next configs you must set the project option to include all of your tsconfig.json files:
{
"extends": "eslint-config-neo/config-backend",
"parserOptions": {
"project": ["tsconfig.json", "test/tsconfig.json"]
}
}Add .prettierrc to project root
{
"printWidth": 120,
"singleQuote": true
}Optional: If there are any files you want to exclude from Prettier add .prettierignore to project root
Add .editorconfig to project root
# http://editorconfig.org
root = true
[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
max_line_length = 120
[*.md]
max_line_length = 0
trim_trailing_whitespace = false
[COMMIT_EDITMSG]
max_line_length = 0Add the engines field to package.json
"engines": {
"node": "^12.0.0"
}Add scripts for linting and formatting to package.json
"scripts": {
"lint": "eslint .",
"format": "prettier --write \"**/*.{ts,tsx,js,json,graphql,md}\"",
"format:check": "prettier --debug-check \"**/*.{ts,tsx,js,json,graphql,md}\""
}Add a precommit hook to package.json to automatically lint and format any files staged for commit
"husky": {
"hooks": {
"pre-commit": "lint-staged"
}
},
"lint-staged": {
"concurrent": false,
"linters": {
"*.{ts,tsx,js}": [
"eslint --quiet",
"git add"
],
"*.{ts,tsx,js,json,graphql,md}": [
"prettier --write",
"git add"
]
}
}If you've added Prettier to an existing project you will want to format all the code. The precommit hook only updates files that have been changed and staged for commit. To format the entire codebase run
npm run format
- requires
eslintversion8.26.0or higher - for backend services, you should delete the domain-specific
eslintrc
Should I override the rule X? I don't like it.
No. If you want to do this, you have to ask the team. If a rule really doesn't make sense then we should remove or disable it.
Can I disable the rule on one line in my code, I have a good reason.
Yes. That's ok. Use a single-line disable.
Sometimes, testing functionality locally using symlinks can be challenging. In such cases, publishing an alpha version for use in other environments can be a practical way to test new changes.
- Make sure the version in
package.jsonis following this format:<<major>>.<<minor>>.<<patch>>-alpha.<<alpha version>>(e.g.1.2.5-alpha.0,1.2.5-alpha.1, etc.). - Make sure all changes including the version bump, lock file and your library changes are committed and pushed to your feature branch.
- Run
npm publish --tag alpha(To be able to publish the new NPM package the user should be included on the NPM Publisher List. If you're not on that list ask for help to publish.)
In some rare situations, we need to test library change versions on a few services in production before rolling out the change to all services that use the library. How it works:
- Make sure the version in
package.jsonis following this format:<<major>>.<<minor>>.<<patch>>-beta.<<beta version>>(e.g.1.2.5-beta.0,1.2.5-beta.1, etc.). - Make sure all changes including the version bump, lock file and your library changes are committed and pushed to your feature branch.
- Open a Pull Request targeting a branch that matches this pattern:
**/*release-candidate*. - After getting approvals, merge your changes into the Release Candidate branch;
- Run
npm publish --tag beta(To be able to publish the new NPM package the user should be included on the NPM Publisher List. If you're not on that list ask for help to publish.)
Once your changes have been tested and you're ready to publish a stable version, open your Pull Request, get approvals, merge it and publish the new package version. How it works:
- Make sure the version in
package.jsonis following this format:<<major>>.<<minor>>.<<patch>>(e.g.1.2.5,1.3.0, etc.). - Make sure all changes including the version bump, lock file and your library changes are committed and pushed to your feature branch.
- Pull request is approved and merged into
masterbranch; - Run
npm publish --tag latest(To be able to publish the new NPM package the user should be included on the NPM Publisher List. If you're not on that list ask for help to publish.)