Why

Naming conventions in software development offer numerous benefits:

• Readability: Consistent naming makes code easier to read and understand, reducing cognitive load when scanning files.
• Maintainability: Enforces best practices, improving code quality and consistency across the codebase.
• Code Review and Collaboration: Eliminates debates on naming styles, allowing reviewers to focus on logic and speeding up the process.
• Code Uniformity: Uniform naming promotes collective code ownership, as code looks the same regardless of who wrote it.
• Aesthetics: Provides functional benefits and aesthetic appeal, with a visually pleasing and harmonious structure.

This config makes naming predictable and review-friendly by enforcing a coherent set of rules that scale well across:

• Apps and Libraries
• Frontend and Backend
• Monorepos and Multi-team codebases

It is intentionally BYO parser setup — it ships rules only and does not assume your repo layout or parserOptions.project.

Documentation

Comprehensive documentation with detailed rule explanations and examples is available at drsmile444.github.io/eslint-config-naming.

Key resources:

• Getting Started Guide — Installation and configuration
• Rule Matrix — Complete rule matrix with examples
• Changelog — Version history and updates

At a Glance

This configuration enforces consistent naming patterns across TypeScript constructs:

| Category | Enforced Style | Example | | ----------------------------- | ----------------------------------------------- | ---------------------------------- | | Types | PascalCase, no I/T prefixes | ApiResponse, UserData | | Classes | PascalCase | HttpClient, DataService | | Interfaces | PascalCase | Config, Options | | Enums | PascalCase (name), UPPER_CASE (members) | enum Status { ACTIVE, INACTIVE } | | Variables | camelCase or UPPER_CASE | userName, MAX_RETRIES | | Booleans | Prefixed with is\|should\|has\|can\|did\|will | isValid, hasAccess | | Functions | camelCase | calculateTotal(), fetchData() | | Class Members (public) | camelCase or snake_case | userCount, api_key | | Class Members (protected) | camelCase (no underscore) | internalState | | Generic Types | Single letter or T-prefixed | T, TData, TKey |

Abbreviations and single-letter variables are restricted — only x, y, z are allowed for coordinates. Descriptive names like errorMessage and index are enforced over vague shortcuts like err, str, or i.

Code Examples

// Type prefixes
interface IApiResponse {}
type TUserData = {};

// Wrong casing
enum status {
  active,
  inactive,
}
class userService {}

// Variables
const Myvariable = 'value';
const my_constant = 'constant';
const ready = true;

// Abbreviations
const str = 'message';

// Generics
type Cache<Key, val> = Map<Key, val>;

// Clean type names
interface ApiResponse {}
type UserData = {};

// Proper casing
enum Status {
  ACTIVE,
  INACTIVE,
}
class UserService {}

// Variables
const myVariable = 'value';
const MY_CONSTANT = 'constant';
const isReady = true;

// Descriptive names
const message = 'message';

// Proper generics
type Cache<TKey, TValue> = Map<TKey, TValue>;

Note: This is a high-level overview and most rules have additional conditions and exceptions. See the Rule Matrix for complete details and examples.

Installation

1. Install peer dependencies

npm i -D eslint typescript typescript-eslint

2. Install this config

npm i -D eslint-config-naming

For other installation options, see Flat Config Usage.

Usage

Option A: Flat Config (ESLint v9+)

// eslint.config.js
import tseslint from 'typescript-eslint';
import namingConfig from 'eslint-config-naming';

export default [
  // Your TS wiring (BYO parserOptions)
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: {
        project: ['./tsconfig.json'],
        tsconfigRootDir: import.meta.dirname,
      },
    },
    plugins: {
      '@typescript-eslint': tseslint.plugin,
    },
  },

  // Naming rules
  ...namingConfig,
];

Option B: Legacy .eslintrc.*

Use the legacy shareable entry:

• eslint-config-naming/legacy

// .eslintrc.cjs
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: ['eslint-config-naming/legacy'],
  parserOptions: {
    project: './tsconfig.json',
  },
};

How it’s structured

Internally, the config is built as a set of small rule fragments grouped by selector:

• memberLike rules (public/private/protected/static/readonly)
• variables rules (default, const/global, destructured, boolean prefixes, *Component)
• types rules (class, interface, enum, typeLike, enumMember, generics)
• parameters rules (base, destructured)
• functions rules (including final camelCase enforcement)
• quoted-key escape hatch (requiresQuotes → ignored)

They are combined in a single @typescript-eslint/naming-convention rule entry list, preserving precedence.

Rule overview

This is a quick “what it enforces” list. For full details (and good/bad examples), check the Rule Matrix..

Types

• class: PascalCase
• interface: PascalCase and forbids I* / T* prefixes
• typeAlias: PascalCase and forbids I* / T* prefixes
• typeParameter: Single uppercase letters (T, U, V, K) or prefixed descriptive names (TData, KKey, VValue) or numeric subscripts (T1, T2, K1, etc.)
• enum: PascalCase, forbids plural-ish names (like Statuses) and I*/T*
• enumMember: UPPER_CASE

Members (memberLike)

• public static: camelCase, PascalCase or UPPER_CASE
• private static: camelCase, PascalCase or UPPER_CASE, no leading _
• readonly: UPPER_CASE, camelCase, or snake_case
• public: camelCase or snake_case
• private: camelCase, no leading _
• private readonly: camelCase or UPPER_CASE, no leading _
• protected: camelCase, no leading _

Variables

• default: camelCase or UPPER_CASE, abbreviation restrictions apply
• const + global: allows PascalCase (in addition to camelCase/UPPER_CASE), abbreviation restrictions apply
• destructured: allows PascalCase, camelCase, snake_case
• booleans: camelCase with required prefix is|are|should|has|can|did|will
• destructured booleans: no prefix requirement (interop friendly)
• *Component: allows PascalCase if variable name ends with Component

Parameters

• default: camelCase, abbreviation restrictions apply
• destructured: allows PascalCase, camelCase, snake_case

Functions

• exported/global: camelCase or PascalCase, abbreviation restrictions apply
• default (catch-all): camelCase, abbreviation restrictions apply

Object Literals

• objectLiteralProperty: camelCase, snake_case, PascalCase, or UPPER_CASE (flexible to support various use cases including constant objects)

Quoted members

If a name requires quotes (e.g. HTTP headers, data contracts), it's ignored.

Abbreviation Restrictions

Automatically bans common abbreviations and anti-patterns:

• Single-letter names: i, j, k, e → use index, itemIndex, error
• Vague abbreviations: str, num, arr, obj → use string, number, array, object
• Intent-hiding names: data, info, tmp → use payload, metadata, temporary
• Ambiguous abbreviations: res, req, dir, cfg → use response, request, directory, config

Well-known technical terms like id, url, api, json, html, uuid are allowed.

See Abbreviation Restrictions docs for the complete list and customization options.

Update policy

This project treats rule and packaging changes as user-facing. Before submitting a change that affects rules, exports, or packaging, please follow the project's update policy (full text in Update Policy Docs). In short, every rule-related change must include:

• Source changes (src/) implementing the rule or selector.
• Tests (tests/) covering both accepted and rejected examples.
• Snippets (tests/snippets/...) for positive/negative cases where applicable.
• Documentation updates in docs/ explaining the rule and examples.
• README updates if usage or exports change.
• Package metadata changes (package.json) such as version bump and export adjustments.

See docs/policies/update-policy.md for the complete checklist, versioning rules, and CI expectations.

License

MIT © 2025-Present Dmytro Vakulenko 🇺🇦