{"dataset":{"id":"00000000-0000-0000-0000-000000000035","slug":"eslint-best-practices","name":"ESLint best practices","description":"Source-linked guidance on ESLint flat config fundamentals: configuration files, rule severity, plugins, ignoring files, and CLI autofix. Scoped to ESLint; not a general JavaScript style corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Autofix with --fix","sourceUrl":"https://eslint.org/docs/latest/use/command-line-interface","text":"The --fix CLI option instructs ESLint to fix as many issues as possible, writing changes to the actual files and outputting only the remaining unfixed issues, as in npx eslint --fix file.js. Not all problems are fixable: the option throws an error when code is piped to ESLint on stdin, and it has no effect on code that uses a processor unless the processor opts into allowing autofixes. To get the fixes without writing them to the file, or to fix code from stdin, use --fix-dry-run instead. The --fix-type option restricts which kinds of fixes --fix or --fix-dry-run applies: problem fixes potential errors, suggestion applies fixes that improve the code, layout applies fixes that do not change the program structure (AST), and directive applies fixes to inline directives such as // eslint-disable. The option may be passed multiple times, for example npx eslint --fix --fix-type suggestion . — useful when another program formats the code but ESLint should still apply other fix types. Scope: ESLint. Reviewed October 4, 2026.","id":"eslint-best-practices:Autofix with --fix","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Ignoring files and directories","sourceUrl":"https://eslint.org/docs/latest/use/configure/ignore","text":"In flat config, files are ignored with the globalIgnores() helper from \"eslint/config\", for example defineConfig([globalIgnores([\".config/*\"])]); these patterns are added after the default ignores [\"**/node_modules/\", \".git/\"]. A trailing slash ignores a directory as a whole so file search does not traverse into it at all; unlike .gitignore, a pattern like .config/ only matches the directory in the same directory as the configuration file, so recursively ignoring directories of that name requires **/.config/. Files ignored by earlier patterns can be unignored with negation patterns such as \"!node_modules/mylibrary/\". To ignore a directory's contents while still permitting unignoring inside it, use directory/**/* instead of directory/**, because directory/** skips traversal completely and nothing inside can be unignored. A config object's own ignores key scopes exclusions to the files that object matches. Files can also be ignored on the command line with --ignore-pattern, for example npx eslint . --ignore-pattern '.config/*'. Scope: ESLint. Reviewed October 4, 2026.","id":"eslint-best-practices:Ignoring files and directories","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Plugins and shared configurations","sourceUrl":"https://eslint.org/docs/latest/use/configure/plugins","text":"ESLint supports third-party plugins, which are objects conforming to an interface ESLint recognizes and can include custom rules, custom configurations, and custom processors that extract JavaScript from other kinds of files. In a flat config file, the plugins key maps a namespace to the plugin object: import example from \"eslint-plugin-example\" and set plugins: { example }; the convention is to use the npm package name without the eslint-plugin- prefix, though any prefix is allowed. Plugin rules are referenced with the namespace prefix, such as \"example/rule1\": \"warn\". Plugins can also be loaded from a local file or defined virtually inline by giving a namespace an object with its own rules map and referencing the rule as namespace/rule-name. Processors are enabled with the processor key in the form \"namespace/processor-name\", for example \"markdown/markdown\" from @eslint/markdown for *.md files; processors can emit named code blocks that ESLint treats as child files, and non-JavaScript code blocks are linted only when they match a files entry. Scope: ESLint. Reviewed October 4, 2026.","id":"eslint-best-practices:Plugins and shared configurations","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Rules and severity levels","sourceUrl":"https://eslint.org/docs/latest/use/configure/rules","text":"Set a rule's severity to \"off\" or 0 to turn it off, \"warn\" or 1 to report violations without affecting the exit code, or \"error\" or 2, which makes ESLint exit with code 1 when triggered. \"error\" is typical for continuous integration testing, pre-commit checks, and pull request merging; \"warn\" suits a rule being introduced on the way to \"error\", a rule flagging something other than a buildtime or runtime error such as an unused variable, or a rule that might have false positives and need manual review. Rules with options use array syntax where the first item is the severity, for example \"prefer-const\": [\"error\", { ignoreReadBeforeAssign: true }]. When multiple configuration objects specify the same rule, the configurations merge with the later object taking precedence. Rules can also be changed per file with configuration comments such as /* eslint eqeqeq: \"off\", curly: \"error\" */, optionally followed by two or more consecutive dashes and a description explaining why the comment is necessary. Scope: ESLint. Reviewed October 4, 2026.","id":"eslint-best-practices:Rules and severity levels","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Flat config with eslint.config.js","sourceUrl":"https://eslint.org/docs/latest/use/configure/configuration-files","text":"ESLint flat configuration lives in eslint.config.js, eslint.config.mjs, or eslint.config.cjs (the eslint.config.ts variants require additional setup), placed in the project root and exporting an array of configuration objects, conventionally wrapped in the defineConfig() helper imported from \"eslint/config\". Each configuration object carries properties such as name, files (glob patterns in minimatch syntax, evaluated relative to the config file), ignores, languageOptions, plugins, rules, and settings. When ignores appears without other keys it acts as a global ignore applied to every configuration object. In languageOptions, ecmaVersion defaults to \"latest\" and sourceType defaults to \"module\" for .js and .mjs files and \"commonjs\" for .cjs files. A configuration object without files or ignores applies to every file matched by any other configuration object. By default ESLint lints files matching **/*.js, **/*.cjs, and **/*.mjs; lint other extensions by adding a \"**/*.extension\" pattern to files, for example files: [\"**/*.ts\", \"**/*.cts\", \"**/*.mts\"] to include TypeScript files. Scope: ESLint. Reviewed October 4, 2026.","id":"eslint-best-practices:Flat config with eslint.config.js","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}