refactor(eslint): reduce empty line rules

[mheob]

Summary

Refactor stylistic ESLint rules to reduce the number of enforced empty lines in code, making the formatting less aggressive while maintaining code readability.

Changes

• Remove padding rules for variable declarations (const, let, var)
• Remove padding rules for block-like statements and return statements
• Add padding rules for export statements (blank lines between exports)
• Add padding rules for function declarations (blank lines around functions)
• Add @stylistic/lines-between-class-members rule requiring blank lines between class members

Motivation

The previous configuration enforced too many empty lines throughout the code, particularly around variable declarations and return statements. This refactor focuses the empty line enforcement on more meaningful boundaries (exports, functions, class members) while allowing more natural grouping of related variable declarations and statements.

Summary by CodeRabbit

• New Features

  • Added rule requiring blank lines between class members.

• Refactor

  • Optimized spacing rules to reduce unnecessary empty lines around variable declarations and block statements, while enforcing consistent blank lines for export and function declarations.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[changeset-bot]

🦋 Changeset detected

Latest commit: 639c675

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@mheob/eslint-config	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
eslint-config	Ready	Preview	Comment	Nov 21, 2025 5:53am

[coderabbitai]

Walkthrough

A changeset introduces modifications to ESLint stylistic rules, reducing unnecessary empty lines by refactoring padding rules around exports and functions, and adding enforcement for blank lines between class members.

Changes

Cohort / File(s)	Summary
Changeset documentation .changeset/reduce-empty-lines.md	Introduces patch-level changeset documenting removal of padding rules around variable declarations and addition of export/function spacing rules and class member line enforcement.
ESLint configuration packages/eslint-config/src/configs/stylistic.ts	Adds @stylistic/lines-between-class-members rule; refactors @stylistic/padding-line-between-statements to replace generic const/let/var and block-like spacing with explicit rules for export statements and function declarations.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify the new export and function spacing rules are correctly configured in stylistic.ts
• Confirm that the changeset accurately reflects the rule modifications made

Suggested labels

eslint

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'refactor(eslint): reduce empty line rules' directly and clearly summarizes the main change—refactoring ESLint stylistic rules to reduce empty line enforcement, which matches the PR's primary objective and file modifications.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch reduce-empty-lines

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[claude]

PR Review: refactor(eslint): reduce empty line rules

Overview

This PR refactors the stylistic ESLint rules to reduce the number of enforced empty lines, focusing on more meaningful code boundaries.

Code Quality ✅

Strengths:

• Clean, well-structured changeset with clear documentation
• The new rules focus on meaningful boundaries (exports, functions, class members) rather than every variable declaration
• Removing the aggressive block-like and return padding rules should improve code readability

Potential Issues ⚠️

1. Export Rules May Be Redundant

The export padding rules at lines 29-31 in stylistic.ts seem overly comprehensive:

{ blankLine: 'always', next: 'export', prev: 'export' },
{ blankLine: 'always', next: '*', prev: 'export' },
{ blankLine: 'always', next: 'export', prev: '*' },

Rule 1 (export → export) is effectively covered by rules 2 and 3. Consider simplifying to just:

{ blankLine: 'always', next: '*', prev: 'export' },
{ blankLine: 'always', next: 'export', prev: '*' },

2. Same Redundancy with Function Rules

Lines 33-35 have the same pattern:

{ blankLine: 'always', next: 'function', prev: 'function' },
{ blankLine: 'always', next: '*', prev: 'function' },
{ blankLine: 'always', next: 'function', prev: '*' },

The first rule is redundant when the other two exist.

3. Consider Arrow Functions and Class Methods

The function keyword only targets function declarations. Consider whether arrow functions (FunctionExpression, ArrowFunctionExpression) and class methods should also have padding. This might be intentional to only enforce on top-level declarations, but worth confirming the desired behavior.

Typegen Changes

The typegen.d.ts changes appear to be whitespace normalization (removing trailing spaces from blank lines), which is a positive side effect of regenerating types.

Suggestions for Consideration

1. Optional: Test with a real codebase to ensure the export rules don't create excessive blank lines in files with many exports (e.g., barrel files like index.ts that re-export multiple modules)

2. Consider exceptAfterSingleLine for class members:

   '@stylistic/lines-between-class-members': ['error', 'always', { exceptAfterSingleLine: true }]

   This would allow compact single-line class members (common for getters/setters or simple properties) while still separating multi-line methods.

Verdict

This is a reasonable refactor that addresses the stated goal of reducing aggressive empty line enforcement. The changes are low-risk for a patch release. The redundant rules noted above are minor style concerns and don't affect functionality.

Approved ✅ with minor suggestions above.

---

🤖 Generated with Claude Code

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

packages/eslint-config/src/configs/stylistic.ts (2)

29-31: Consider removing redundant export spacing rule.

The rule on line 29 (export → export) is redundant since lines 30 and 31 together already enforce blank lines between consecutive exports:

• Line 30: requires blank line from export to any statement (including export)
• Line 31: requires blank line from any statement (including export) to export

While harmless, removing the redundant rule would simplify the configuration.

Apply this diff to remove the redundant rule:

 					{ blankLine: 'always', next: '*', prev: 'directive' },
 					{ blankLine: 'any', next: 'directive', prev: 'directive' },
 
-					{ blankLine: 'always', next: 'export', prev: 'export' },
 					{ blankLine: 'always', next: '*', prev: 'export' },
 					{ blankLine: 'always', next: 'export', prev: '*' },

---

33-35: Consider removing redundant function spacing rule.

Similar to the export rules, line 33 (function → function) is redundant since lines 34 and 35 together already enforce blank lines between consecutive functions:

• Line 34: requires blank line from function to any statement (including function)
• Line 35: requires blank line from any statement (including function) to function

Removing this redundancy would keep the configuration consistent and simplified.

Apply this diff to remove the redundant rule:

 					{ blankLine: 'always', next: 'export', prev: '*' },
 
-					{ blankLine: 'always', next: 'function', prev: 'function' },
 					{ blankLine: 'always', next: '*', prev: 'function' },
 					{ blankLine: 'always', next: 'function', prev: '*' },
 				],

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bd5c5c3 and 639c675.

📒 Files selected for processing (2)

• .changeset/reduce-empty-lines.md (1 hunks)
• packages/eslint-config/src/configs/stylistic.ts (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.{ts,tsx}

📄 CodeRabbit inference engine (.cursor/rules/any-inside-generic-functions.mdc)

**/*.{ts,tsx}: When building generic functions in TypeScript, it is acceptable to use 'any' inside the function body if TypeScript cannot match runtime logic to type logic.
Outside of generic functions, use 'any' extremely sparingly in TypeScript code.

Unless explicitly required by the framework, do not use default exports in TypeScript files.

**/*.{ts,tsx}: Use TypeScript for all code. Prefer interfaces over types.
Follow the ESLint rules.
Use "function" keyword for pure functions.
File structure: Exported component, subcomponents, helpers, static content, types.
Avoid unnecessary curly braces in conditional statements.
For single-line statements in conditionals, omit curly braces.
Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).
Handle errors and edge cases at the beginning of functions.
Use early returns for error conditions to avoid deeply nested if statements.
Place the happy path last in the function for improved readability.
Avoid unnecessary else statements; use if-return pattern instead.
Use guard clauses to handle preconditions and invalid states early.
Implement proper error logging and user-friendly error messages.
Consider using custom error types or error factories for consistent error handling.
Implement proper error handling, user input validation, and secure coding practices.
Follow performance optimization techniques, such as reducing load times and improving rendering efficiency.
Provide clear and concise comments for complex logic.
Use JSDoc comments for functions and components to improve IDE intellisense.

**/*.{ts,tsx}: Proactively use discriminated unions to model data that can be in one of a few different shapes.
Use switch statements to handle the results of discriminated unions.
Use discriminated unions to prevent the 'bag of optionals' problem (i.e., avoid interfaces with multiple optional properties that can represent impossible states).

**/*.{ts,tsx}: Do not introduce new en...

Files:

• packages/eslint-config/src/configs/stylistic.ts

🧠 Learnings (1)

📚 Learning: 2025-10-21T05:24:57.572Z

Learnt from: mheob
Repo: mheob/config PR: 313
File: .changeset/funny-sloths-live.md:1-2
Timestamp: 2025-10-21T05:24:57.572Z
Learning: In the mheob/config repository, empty changeset files (containing only `---\n---`) are acceptable and used intentionally for documentation-only changes that don't require version bumps.

Applied to files:

• .changeset/reduce-empty-lines.md

🔇 Additional comments (2)

.changeset/reduce-empty-lines.md (1)

1-11: LGTM! Changeset accurately documents the refactoring.

The changeset file correctly documents the patch version bump and provides a clear, comprehensive list of changes that align with both the PR objectives and the actual code modifications.

packages/eslint-config/src/configs/stylistic.ts (1)

23-23: LGTM! Class member spacing rule added correctly.

The lines-between-class-members rule is properly configured to require blank lines between class members, aligning with the PR's objective to enforce spacing at meaningful boundaries.