A configuration records project decisions about how a tool behaves. For ESLint, it selects rules, their settings, and the severity of violations. For Prettier, it changes selected formatting preferences while leaving the rest of its standard ruleset in place. Both let a team make consistent choices without specifying every behavior from scratch. section 4.1.2 section 4.2.2
{
"rules": {
"semi": ["error", "always"],
"quotes": ["error", "double"]
}
}
An ESLint rules block can require semicolons and double quotes, treating violations of either rule as errors. If a predefined ruleset is close to what the team wants, extend it and configure only the differences. section 4.1.3 section 4.1.2
Initialize ESLint with `npm init @eslint/config`, then edit the generated root-level `.eslintrc.{js,yml,json}` file. Its `extends` property can adopt a ruleset such as `eslint:recommended`; its `rules` block specifies local decisions. Enforce the result in the editor and build so violations appear during development as well as in the project workflow. section 4.1.3
A formatting preference without a full rule rewrite
To use tabs and omit semicolons, invoke Prettier as `prettier --use-tabs --no-semi src/`, or put those preferences in a root-level `.prettierrc` or `.prettierrc.json`. The file is useful when the choice should persist across invocations. Prettier still controls formatting choices that the project has not customized. section 4.2.2
Prettier needs no configuration file when its standard formatting is acceptable. Editor integration can apply formatting as code is written; an optional precommit check can catch changed files that bypassed the editor, including changes produced by a merge. Choose that extra enforcement when the workflow warrants it. section 4.2.3
