Enforce consistent comment styles: single-line (
//) for code, multi-line (/* */) for documentation
An ESLint plugin that automatically detects and enforces the appropriate comment style based on content. Commented-out code uses //, while documentation and explanatory text use /* */.
I want to have a clear distinction between commented-out code and documentation.
Commented-out code should probably be removed from production code, while documentation should stay.
- π€ Smart Detection - Automatically identifies code vs. documentation in comments using AST parsing
- π§ Auto-fix - Converts comments to the correct style with
eslint --fix - π Smart Merging - Consecutive single-line text comments are merged into multi-line block format
- π‘οΈ Safe Conversion - Avoids breaking comments that contain
*/in their text - π¦ ESLint 9.x - Compatible with modern flat config format
- π― TypeScript & JavaScript - Works with both languages
- β‘ Zero Config - Works out of the box with sensible defaults
npm install eslint-plugin-consistent-comments --save-devOr using your preferred package manager:
pnpm add -D eslint-plugin-consistent-comments
# or
yarn add -D eslint-plugin-consistent-commentsAdd to your eslint.config.js:
import commentsPlugin from 'eslint-plugin-consistent-comments';
export default [
{
plugins: {
comments: commentsPlugin,
},
rules: {
'comments/comment-style': 'error',
},
},
];Then run ESLint with auto-fix:
npx eslint . --fixInconsistent comment styles make code harder to read:
/* const oldCode = 'should be single-line'; */ // β Code in multi-line
// This explains the function below // β Text in single-lineThis plugin enforces:
// const oldCode = 'should be single-line'; // β
Code in single-line
/* This explains the function below */ // β
Text in multi-lineWhen multiple single-line text comments appear consecutively (without empty lines), they're automatically merged into a multi-line block comment:
Before:
// This is a documentation comment
// that spans multiple lines
// for better readabilityAfter:
/*
* This is a documentation comment
* that spans multiple lines
* for better readability
*/The plugin uses AST (Abstract Syntax Tree) parsing to accurately detect code, not just regex patterns. It recognizes:
- Declarations:
const,let,var,function,class,interface,type,enum - Control Flow:
if,else,for,while,switch,return,throw - Functions:
function foo(),() => {}, arrow functions - Imports/Exports:
import,export - Method Calls:
obj.method(),foo() - Operators: Assignments, comparisons
- Data Structures: Arrays
[...], objects{...} - Type Annotations:
: string,: number - JSX:
<Component /> - Expressions:
true,42,"string", object/array literals
The plugin intelligently handles edge cases:
Comments that contain */ in their text are not converted to multi-line format to avoid breaking syntax:
// These should NOT be converted to /* */ (results in invalid code)
// β
Stays as single-line comment to prevent syntax errorsTypeScript directives and special comment forms are preserved:
/// <reference types="node" /> // β
Not converted
// @ts-ignore: special case // β
Not converted
// eslint-disable-next-line no-unused-vars // β
Not converted/* const x = 5; */
/* function test() { return true; } */
// This is a documentation comment
// that spans multiple lines
/*
const multiple = 'lines';
const of = 'code';
*/// const x = 5;
// function test() { return true; }
/*
* This is a documentation comment
* that spans multiple lines
*/
// const multiple = 'lines';
// const of = 'code';import commentsPlugin from 'eslint-plugin-consistent-comments';
export default [
{
plugins: {
comments: commentsPlugin,
},
rules: {
...commentsPlugin.configs.recommended.rules,
},
},
];import commentsPlugin from 'eslint-plugin-consistent-comments';
import tseslint from 'typescript-eslint';
export default [
...tseslint.configs.recommended,
{
plugins: {
comments: commentsPlugin,
},
rules: {
'comments/comment-style': 'error',
},
},
];Currently, the rule has no options and works with sensible defaults. Future versions may add configuration options.
Clone this repository, install dependencies, and run tests:
# Install dependencies
pnpm install
# Run tests
pnpm test
# Run tests with coverage
pnpm run coverage
# Build the plugin
pnpm buildTry the demo:
# Check for violations
node demo.mjs
# Auto-fix violations
node demo.mjs --fixsrc/
index.ts # Main plugin implementation
tests/
index.test.ts # Test suite
fixtures/ # Test fixtures
examples/
before-fix.ts # Example with violations
after-fix.ts # Example after fixes
integration-example.ts # Comprehensive examples
pnpm buildβ Build with unbuild (outputs CJS/ESM and type declarations)pnpm testβ Run tests with Vitestpnpm test:watchβ Run tests in watch modepnpm coverageβ Generate coverage reportspnpm lintβ Run ESLint and auto-fix issuespnpm typecheckβ Run TypeScript type checks
Contributions are welcome! Please feel free to submit a Pull Request.
- Fork the repository
- Create your feature branch (
git checkout -b feature/amazing-feature) - Commit your changes (
git commit -m 'Add amazing feature') - Push to the branch (
git push origin feature/amazing-feature) - Open a Pull Request
MIT Β© Johan Meester
- ESLint - Pluggable JavaScript linter
- typescript-eslint - TypeScript support for ESLint
The plugin uses a sophisticated approach to distinguish between code and text:
- AST Parsing: Uses
espree(ESLint's parser) to attempt parsing comment content as JavaScript/TypeScript - Multiple Parse Attempts: Tries parsing as:
- Complete program (statements)
- Expression (wrapped in parentheses)
- Statement (wrapped in a function body)
- Accurate Detection: If the content parses successfully, it's code; otherwise, it's text
- Consecutive Grouping: Merges consecutive single-line text comments into multi-line blocks
- Safety First: Skips conversion when it would create invalid syntax
This approach is far more reliable than regex patterns and handles edge cases like:
/* true */β// true(valid code, single boolean value)/* This is true */β stays as/* This is true */(text, not code)
This plugin was created to enforce a consistent commenting style that makes it easier to:
- Distinguish between commented-out code (temporary, should be reviewed/removed)
- Documentation comments (permanent, explains intent)
- Keep documentation organized in proper multi-line block format
For more detailed documentation, see:
- USAGE.md - Comprehensive usage guide
- QUICKSTART.md - Quick start guide
- PROJECT_SUMMARY.md - Project summary and implementation details
Made with β€οΈ for better code consistency