Skip to content

Fix prettier↔eslint config drift on comma-dangle functions#57

Closed
senoff wants to merge 3 commits into
protobi:masterfrom
senoff:fix/prettier-eslint-config-drift
Closed

Fix prettier↔eslint config drift on comma-dangle functions#57
senoff wants to merge 3 commits into
protobi:masterfrom
senoff:fix/prettier-eslint-config-drift

Conversation

@senoff
Copy link
Copy Markdown

@senoff senoff commented May 2, 2026

Problem

The prettier and eslint configs were in direct conflict, causing the lint-staged pre-commit hook to fail on innocuous commits:

  • .prettierrc had "trailingComma": "all" → adds trailing commas to every multi-line construct, including function call arguments
  • .eslintrc had "comma-dangle": {"functions": "never"} → rejects trailing commas on function calls/declarations

The hook runs prettier first, then eslint. Any commit touching a file with pre-existing multi-line function calls would get a trailing comma injected by prettier, then immediately rejected by eslint — even when the actual change was completely unrelated. The only workaround was collapsing multi-line function constructs to single-line to dodge the hook.

Three additional secondary conflicts were also present:

  • space-before-function-paren (anonymous: "never"): prettier normalizes anonymous functions to function () (with space); eslint required no space
  • quotes ("single"): prettier uses double quotes for strings containing a single quote (to avoid escaping); eslint required single quotes unconditionally
  • import/extensions: CommonJS require() patterns in test/spec files include .js extensions, which the rule incorrectly flagged — it was never passing cleanly

Fix

  1. .prettierrc: Change "trailingComma" from "all" to "es5". This matches eslint's intent — trailing commas on objects and arrays (es5-valid), but NOT on function calls/declarations. The comma-dangle eslint rule is left untouched (changing the prettier config is lower-risk).

  2. .eslintrc (secondary fixes):

    • space-before-function-paren: set anonymous from "never" to "ignore" so prettier controls the style
    • quotes: add "avoidEscape": true to allow double quotes when a string contains a single quote (matches prettier's behavior)
    • import/extensions: set to "off" — this rule doesn't apply meaningfully to a CommonJS Node.js project
    • max-len: add ignoreTemplateLiterals: true to match the intent of the existing ignoreStrings option

Alternative considered: changing the eslint comma-dangle functions rule from "never" to "all" instead of changing prettier. Rejected because it would require adding trailing commas to all existing function calls across the codebase — a much larger diff with higher review burden for upstream.

Normalization

Ran npx prettier --write . after the config changes to bring all files into the new consistent state. All changes are purely cosmetic (quote normalization, bracket spacing, line wrapping). No behavior was altered.

Testing

  • npm run test:unit: 884 passing, 0 failing
  • npm run test:integration: 200 passing, 0 failing
  • npm run test:end-to-end: 1 passing, 0 failing
  • Pre-commit hook: passes without --no-verify

Verification

Post-merge, contributors can verify by making any small change to a file with multi-line function calls and confirming the hook no longer fails.

senoff added 3 commits May 1, 2026 19:45
The two formatter configs were in direct conflict:
- .prettierrc had "trailingComma": "all" → adds trailing commas on
  every multi-line construct, including function call arguments
- .eslintrc had "comma-dangle": {"functions": "never"} → rejects
  trailing commas on function calls/declarations

The lint-staged hook runs prettier first, then eslint. Any commit
touching a file with pre-existing multi-line function calls would
get a trailing comma injected by prettier and then immediately
rejected by eslint — even if the actual change was unrelated. This
forced drive-by workarounds across prior PRs (collapsing multi-line
function constructs to single-line just to dodge the hook).

Resolution: change .prettierrc to "trailingComma": "es5".
This matches eslint's intent — trailing commas on objects and
arrays (es5-valid), but NOT on function calls or declarations.
The eslint comma-dangle config is left untouched (lower-risk).

Two secondary conflicts in .eslintrc were also fixed:

1. space-before-function-paren (anonymous: "never"): prettier
   normalizes anonymous functions to "function ()" with a space;
   eslint enforced no space. Changed anonymous to "ignore" so
   prettier controls the style without eslint rejecting it.

2. quotes ("single"): prettier uses double quotes for strings
   containing a single quote (to avoid escaping); eslint required
   single quotes unconditionally. Added "avoidEscape": true to the
   quotes rule to match prettier's behavior.

3. import/extensions: disabled. CommonJS require() patterns in
   this codebase include .js extensions, which the rule incorrectly
   flags. Rule was never passing cleanly in test/spec files.

4. max-len: added ignoreTemplateLiterals: true to match the intent
   of the existing ignoreStrings option.

Codebase normalization: ran "npx prettier --write ." after the
config changes to bring all files into the new consistent state.
All changes are purely cosmetic (quote style, bracket spacing,
line wrapping). No behavior was altered.

Test result: 884 + 200 + 1 passing, 0 failing (mocha unit +
integration + end-to-end suites green).
@senoff
Copy link
Copy Markdown
Author

senoff commented May 3, 2026

Local test run on this branch — npm install --legacy-peer-deps && npm run test:unit && npm run test:integration:

Tier This PR Baseline (master @ 4c9e73c) Δ
test:unit 884 passing, 1 pending, 0 failing 884 passing, 1 pending, 0 failing ±0 (config-only PR, no test changes)
test:integration 200 passing, 0 failing 200 passing, 0 failing ±0 (config-only PR, no test changes)

No regressions vs baseline. Skipped test:end-to-end + test:jasmine (browser/grunt tiers) — same regression-catching surface for unit + integration on a feature branch like this one.

Posted because the tests.yml workflow at this repo hasn't auto-fired on this PR (GitHub's first-time-contributor approval gate). Just want to make the merge feel less risky if/when you get to it. Happy to wait for the official CI run if you'd prefer to flip the approval gate; this is purely supplementary.

@senoff
Copy link
Copy Markdown
Author

senoff commented May 7, 2026

Regenerated per AGENTS.md guidance — see new PR #69. Closing this one in favor of the regenerated version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant