@codacy/tools-eslint-8

Table of Contents

• Overview
• Coexistence with ESLint 9
• Updating patterns
• Updating the ESLint version
• Development
• Notes for maintainers

Overview

JavaScript/TypeScript linter using ESLint 8 with the legacy config format (.eslintrc). Uses the Library execution strategy — calls the ESLint API directly rather than spawning a subprocess.

Coexistence with ESLint 9

This adapter coexists safely with @codacy/tools-eslint-9 in the same monorepo and the same Node.js process. Key design decisions:

• pnpm isolation: Each adapter has its own node_modules/eslint symlink pointing to a different version in the pnpm store. import("eslint") from each adapter's built output resolves to the correct version.
• Inline types: ESLint API types are defined inline (not imported from the eslint package) to avoid TypeScript declaration conflicts.
• Separate plugin registries: Plugins that need different versions for ESLint 8 vs 9 (e.g. @typescript-eslint, react-hooks) are installed at the correct version in each adapter's own dependencies.
• Lint script: Uses the root's ESLint 9 for linting source code (node ../../../node_modules/eslint/bin/eslint.js) to avoid the local ESLint 8 binary conflicting with the root's flat config.

Updating patterns

# Re-fetch pattern metadata from the Codacy API
pnpm prefetch

# Commit the result
git add src/patterns.json

Pattern IDs use the codacy-eslint encoding: _ → __, / → _. Examples:

• ESLint8_no-unused-vars (core rule)
• ESLint8_@typescript-eslint_no-unused-vars (scoped plugin)
• ESLint8_react_jsx-no-target-blank (non-scoped plugin)

Updating the ESLint version

ESLint 8 is end-of-life (October 2024). Version updates are not expected. This adapter targets the final 8.57.x release. For newer ESLint, use the eslint-9 adapter.

Development

pnpm build    # Build with tsup
pnpm test     # Run tests

Notes for maintainers

• Preset mappings (src/pattern-mappings.json): prefixes only. @stylistic's JSX rules live under ESLint8_@stylistic_ beside that plugin's framework-agnostic rules, so the react key names the ESLint8_@stylistic_jsx- sub-prefix explicitly. Codacy tags those rules reactjs, but gating on the tag is wrong here: the same tag sits on ESLint8_functional_no-classes ("no ES6 classes anywhere"), css-modules_no-undef-class and test-selectors_onChange, none of which are React rules — and because filterAutoPatterns ORs matched keys, a tag also drags in rules prefix-owned by other keys entirely. Measured on an ordinary React login form, tag gating produced 15 findings from rules the project had no reason to enable. Same reasoning for the Vue SFC custom-block rules, named as ESLint8_jsonc_vue-custom-block / ESLint8_yml_vue-custom-block.
• ESLint 8 uses the legacy config format (.eslintrc.*). The adapter generates legacy config objects with plugins as string names, parser as an absolute path, and overrides for TypeScript-specific configuration.
• No executable config files: .eslintrc.js, .eslintrc.cjs, and the extensionless .eslintrc are excluded from local config detection because those formats can directly execute repo-controlled code. Only static formats (.eslintrc.yaml, .eslintrc.yml, .eslintrc.json) are detected. Note: this does not fully eliminate code execution when local configs are enabled — ESLint legacy config fields like extends and parser can still resolve to repo-controlled modules.
• Plugin resolution: resolvePluginsRelativeTo points ESLint at this adapter's package root so it finds plugins in our node_modules rather than the user's repo.
• Always-on TS parser override: A .ts/.tsx override with @typescript-eslint/parser is always created when any rules are enabled — not just when @typescript-eslint rules are present. This ensures all plugins (e.g. jsdoc) can analyze TypeScript files correctly, and that core rules like no-redeclare and no-undef are unconditionally disabled for TS files (TypeScript's compiler handles them natively).
• No project: true: The TS parser override does not use project: true because it fails when no tsconfig.json covers the target files. Most @typescript-eslint rules work without type information; type-aware rules degrade gracefully.
• Pattern IDs use the same encoding as the codacy-eslint wrapper: _ → __ then / → _ (encode), reverse for decode.
• The blacklist.ts contains rules known to crash ESLint or produce severe false positives, shared with the ESLint 9 adapter's blacklist.
• checkAvailability verifies that the loaded ESLint version starts with 8. to prevent accidental use of ESLint 9.
• The tool is an npm payload, not a dependency: it is resolved at run time (a Codacy-managed install under ~/.codacy/tools/<id>/, a CODACY_TOOL_ROOT_<ID> root, or this package's own node_modules in the monorepo) and install runs npm ci against the committed payload/package-lock.json. See src/payload.ts.