eslint-config-echo

Enterprise ESLint config package that ships dual v8/v9 flat-config presets aligned to Prettier-first formatting, Sonar, and Jest workflows — standardizing dev setup while enforcing consistent quality gates across repositories.

📊 Project Stats

🗣️ Languages & Runtime

🔧 Quality & Standards

🤖 AI Contributors

Features

• 🔄 Dual ESLint Support: Seamlessly works with both ESLint v8 (legacy .eslintrc format) and v9 (flat config format), providing maximum compatibility across different project setups and team preferences
• ✨ Prettier Enforced: Runs Prettier as an ESLint rule (prettier/prettier) and disables conflicting formatting rules
• 🧠 Sonar Baseline: Includes eslint-plugin-sonarjs recommended rules for code-smell detection; this config also enforces ESLint's no-warning-comments rule, so // nosonar and /* eslint-disable */ comments will trigger errors to maintain quality gates
• 🧹 Unused Imports: Flags dead imports (eslint-plugin-unused-imports)
• 🧾 YAML Linting: Includes eslint-plugin-yml recommended rules

Dual ESLint Support Explained

This configuration provides maximum compatibility by supporting both ESLint v8 and v9, allowing teams to adopt modern linting practices without breaking existing workflows.

When to Use ESLint v9 (Flat Config)

Recommended for new projects or when modernizing existing ones:

• ✅ Future-proof: ESLint v9's flat config is the direction of the ecosystem
• ✅ ESM-first: Native support for ES modules and modern JavaScript
• ✅ Performance: Faster configuration loading and resolution
• ✅ Simplicity: Single configuration file instead of multiple .eslintrc files

File naming: eslint.config.mjs (ESM) or eslint.config.js (with "type": "module")

When to Use ESLint v8 (Legacy Config)

Best for existing projects that need stability:

• ✅ Proven stability: Battle-tested in production environments
• ✅ Gradual migration: Can coexist with existing .eslintrc files
• ✅ Tool compatibility: Some tools and plugins still expect legacy format
• ✅ Team familiarity: Many developers are already comfortable with .eslintrc

File naming: eslint.config.cjs (CommonJS flat config) or .eslintrc.js (legacy)

Migration Strategy

From ESLint v8 to v9:

1. Keep your existing v8 setup working
2. Add ESLint v9 flat config alongside (eslint.config.cjs)
3. Test both configurations in parallel
4. Gradually migrate teams and CI/CD
5. Remove legacy config when ready

Both configurations use the same rule set, ensuring consistent code quality regardless of ESLint version.

Installation

npm install --save-dev @checkmarkdevtools/eslint-config-echo eslint prettier

or

yarn add -D @checkmarkdevtools/eslint-config-echo eslint prettier

Usage

ESLint v9 (ESM / Flat Config)

Create or update your eslint.config.mjs:

import echoConfig from '@checkmarkdevtools/eslint-config-echo';

export default [
  ...echoConfig,
  // Your custom configurations
];

Or in eslint.config.js if your project has "type": "module" in package.json:

import echoConfig from '@checkmarkdevtools/eslint-config-echo';

export default [
  ...echoConfig,
  // Your custom configurations
];

ESLint v8 (Legacy / .eslintrc.*)

Create or update your .eslintrc.cjs:

module.exports = {
  extends: ['@checkmarkdevtools/eslint-config-echo'],
  // Your project-specific overrides
};

ESLint v9+ (Flat Config, CommonJS projects)

If your project is CommonJS-only but you want flat config, use the explicit flat entrypoint:

const echoConfig = require('@checkmarkdevtools/eslint-config-echo/flat');

module.exports = [
  ...echoConfig,
  // Your custom configurations
];

Examples

The ./examples folder contains copy-pasteable configs:

• examples/eslint.config.mjs — ESLint v9 flat config (recommended)
• examples/.eslintrc.cjs — ESLint v8 legacy .eslintrc config (extends this package)

See examples/README.md for the minimal index.

## Configuration Details

### Included Plugins

- **eslint-plugin-prettier** + **eslint-config-prettier**: Enforces Prettier (`prettier/prettier`) and disables conflicting formatting rules
- **eslint-plugin-sonarjs**: Sonar rule presets
- **eslint-plugin-unused-imports**: Flags unused imports
- **eslint-plugin-yml**: YAML linting rules

### Key Rules

- **No Console**: `console.*` is an error
- **Unused Imports**: Dead imports are an error
- **Modernization**: Prefer newer safer APIs (primarily via SonarJS)

### Test File Support

Test files get extra restrictions (no try/catch and no catch clauses) to force explicit error assertions.

### Customization

Append your own config objects after the shared config:

```javascript
import echoConfig from '@checkmarkdevtools/eslint-config-echo';

export default [
  ...echoConfig,
  {
    rules: {
      // Override any rules here
      'no-console': 'warn',
    },
  },
];

Prettier Integration

This config requires Prettier and enforces it through ESLint.

Precedence is intentional:

1. Prettier formatting (must win)
2. SonarJS (quality rules)
3. Everything else

Create a .prettierrc:

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2
}

Note: This config explicitly disables Sonar's trailing-comma rule (sonarjs/enforce-trailing-comma) to avoid conflicts with Prettier.

Commitlint Integration

The repository includes commitlint configuration following conventional commits:

npm install --save-dev @commitlint/cli @commitlint/config-conventional

Scripts

Add these scripts to your package.json:

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint . --fix",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Version Compatibility

• ESLint: v8.x or v9.x
  • ESLint v10: planned. This repo includes a forward-compat export setup and a conditional test hook, but cannot be verified until eslint@10 is published.
• Node.js: >= 24
• Prettier: required (v3.x)

About the License ⚖️

This project exists to standardize linting behavior across environments. It’s meant to be used, extended, and reused inside real codebases without ceremony.

You’re free to use this configuration, fork it, adapt it for your own projects, and run it internally. That’s the expected use case.

What you can’t do is package it as a paid product, service, or commercial offering without permission. If this configuration becomes part of something you sell or monetize, that requires a conversation first.

This repository is licensed under the PolyForm Shield License 1.0.0. Public forks or substantial reuse require attribution. No warranties are provided, no endorsements are implied, and if it breaks, that’s on whoever wired it in. 💎

Contributing

Contributions are welcome! Please follow the conventional commits specification for commit messages.

Support

For issues and questions, please use the GitHub Issues page.