Contributing

Thank you for your interest in contributing to eslint-plugin-code-style. This guide covers how to set up the project, understand the codebase, and submit changes.

Getting Started

Clone the repository and install dependencies:

terminal
bash
git clone https://github.com/Mohamed-Elhawary/eslint-plugin-code-style.gitcd eslint-plugin-code-stylenpm install

Build the plugin:

terminal
bash
npm run build

The build step uses esbuild to bundle all source files into dist/index.js. You must run the build after making changes before testing.

Project Structure

The plugin is organized into 17 category files under src/rules/. Each file exports one or more rule objects:

project structure
text
eslint-plugin-code-style/├── src/│   ├── rules/│   │   ├── arrays.js│   │   ├── arrow-functions.js│   │   ├── call-expressions.js│   │   ├── classes.js│   │   ├── comments.js│   │   ├── components.js│   │   ├── control-flow.js│   │   ├── functions.js│   │   ├── hooks.js│   │   ├── imports-exports.js│   │   ├── jsx.js│   │   ├── objects.js│   │   ├── react.js│   │   ├── spacing.js│   │   ├── strings.js│   │   ├── typescript.js│   │   └── variables.js│   ├── utils/│   │   └── tailwind.js│   └── index.js├── _tests_/│   ├── v9/│   │   ├── react/│   │   ├── react-ts/│   │   ├── react-tw/│   │   └── react-ts-tw/│   └── v10/│       ├── react/│       ├── react-ts/│       ├── react-tw/│       └── react-ts-tw/├── dist/│   └── index.js├── docs/│   └── website/├── package.json└── esbuild.config.js

Key files

  • src/index.js — Main entry point. Registers all rules and defines the 4 preset configs.
  • src/rules/*.js — 17 category files containing all 81 rules.
  • src/utils/tailwind.js — Shared utilities for Tailwind-related rules.
  • esbuild.config.js — Build configuration. Bundles to ESM format targeting Node 20.

Rule Implementation Pattern

Every rule follows the standard ESLint rule structure. Here is a simplified example:

src/rules/arrays.js
js
1// src/rules/arrays.js2 3const arrayCallbackDestructure = {4    meta: {5        type: "layout",6        docs: {7            description: "Enforce destructured properties on separate lines",8        },9        fixable: "whitespace",10        schema: [],11    },12    create(context) {13        return {14            // AST visitor methods15            CallExpression(node) {16                // Rule logic here17                context.report({18                    node,19                    message: "Each destructured property should be on its own line",20                    fix(fixer) {21                        // Auto-fix logic22                    },23                });24            },25        };26    },27};

Guidelines for new rules

  • Place the rule in the appropriate category file under src/rules/.
  • Include a fixable property in meta whenever the fix is safe and deterministic.
  • Write clear, actionable error messages.
  • Add the rule to src/index.js in both the plugin rules map and the relevant preset configs.
  • If the rule is TypeScript-only, only add it to react-ts and react-ts-tw configs.

Testing

The project uses 4 test projects that reference the built plugin via "file:../..". Each project covers a different stack:

Test ProjectStackRules
_tests_/v9/react/JavaScript + React72
_tests_/v9/react-ts/TypeScript + React81
_tests_/v9/react-tw/JavaScript + React + Tailwind72
_tests_/v9/react-ts-tw/TypeScript + React + Tailwind81

To test your changes:

  1. Run npm run build from the project root.
  2. Navigate to the appropriate test project and run ESLint:
terminal
bash
cd _tests_/v9/react-tsnpx eslint . --fix

Test your rule against all 4 projects to ensure it works correctly across stacks.

Build

The plugin uses esbuild to bundle all source files into a single dist/index.js file (~269 KB minified). The build configuration:

  • Format: ESM
  • Platform: Node
  • Target: Node 20
  • Injects __VERSION__ at build time from package.json
terminal
bash
npm run build

Commit Conventions

Follow the conventional commit format for commit messages:

  • feat: — New rule or feature
  • fix: — Bug fix in an existing rule
  • docs: — Documentation changes
  • refactor: — Code refactoring without behavior changes
  • chore: — Build, tooling, or dependency updates

Next Steps