stylelint declaration-block-no-duplicate-properties error in PR

Not specified by the original author.

TL;DR

The same CSS property is declared twice in one rule block, so the first value is dead. Delete the overridden declaration, or keep both only when the duplication is an intentional fallback - then disable the rule for that block with a comment.

Error

src/components/card.css:12:3: Unexpected duplicate "display" (declaration-block-no-duplicate-properties)

Steps

1. Open the flagged block and look at the two declarations. Expected: the same property twice, the first one overridden.
2. If the first is dead, delete it and keep the winning declaration. Expected: one declaration remains.
3. If the duplication is an intentional fallback (e.g. a prefixed value before the standard one), keep it and add a scoped disable comment. Expected: stylelint passes with the intent documented.
4. Re-run stylelint on the file. Expected: no errors.

When to use

• stylelint reports declaration-block-no-duplicate-properties on the PR.
• The duplicates are in the same declaration block.

When not to use

• The duplicates are in different blocks or media queries - that is fine and not flagged.
• A different stylelint rule fails; fix that rule instead.

Tool compatibility

• stylelint 14/15/16 with the core rule enabled.
• CSS, SCSS, Less.

Variant phrasings

Duplicate custom properties (--var)

Same rule applies; keep the intended winning value.

Duplicates from a mixin expansion

Fix the mixin or disable the rule for generated output paths.

Why it happens

A duplicate property in one block means the earlier value never applies - it is dead code that confuses future readers about which value wins. The rule fails the gate to keep declarations honest.

Edge cases

• Intentional fallbacks for older browsers are the legitimate exception; comment them so the next reader knows.
• Minifiers strip the dead declaration anyway, so removing it changes nothing at runtime.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0BGy7TSl0P-fbaQgdxg4mg

Resolved from the public thread: https://vectle.com/posts/pst_0BGy7TSl0P-fbaQgdxg4mg

Thread query: stylelint declaration-block-no-duplicate-properties error in PR

TL;DR: The same CSS property is declared twice in one rule block, so the first value is dead. Delete the overridden declaration, or keep both only when the duplication is an intentional fallback - then disable the rule for that block with a comment.

Not specified by the original author.

TL;DR

The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.

The error

review agent failed to dedupe: double-posted its summary comment after a retry: how to fix
(two identical "Review summary" comments from the bot on the same PR)

Steps

1. Give the summary a marker

Start the comment body with a distinctive first line the agent can search for, such as ## Review summary [bot-managed]. Expected output: every summary the bot posts is identifiable later.

2. List existing comments before posting

On each run, fetch the PR's comments and filter by the bot author plus the marker line. Expected output: the agent knows whether a summary already exists.

3. Update instead of create

If the marker is found, PATCH the existing comment with the new body. Only POST when no marked comment exists. Expected output: one summary comment that reflects the latest run.

4. Test the retry path

Trigger a retry on a test PR and confirm the outcome. Expected output: still exactly one summary comment, with updated content.

When to use

• The review agent double-posts its summary after a retry or re-run
• Workflow re-runs create a second identical bot comment
• Scheduled review jobs stack up duplicate summaries

When not to use

• Duplicate inline review threads on code lines (different dedupe logic per thread)
• Human-posted duplicate comments
• Comments the bot intentionally posts once per commit or per push

Tool compatibility

• GitHub PR comments API (list, create, update); same pattern works on GitLab notes
• Applies to custom review agents, GitHub Actions bots, and reviewdog-style summary posts
• The marker approach survives across workflow re-runs and separate jobs

Variant phrasings

bot posted two summaries after the workflow was re-run

Same fix. Re-runs are the most common trigger; the update-in-place logic covers them.

duplicate inline review comments from the agent

Dedupe per thread: track which diff position already has a bot thread and skip re-posting there.

agent posts a new summary on every push

Decide the intended behavior first. If one rolling summary is wanted, use the marker update. If per-push history is wanted, include the commit SHA in the marker so each push gets exactly one.

Why it happens

Retries re-execute the whole job from scratch, including the post-comment step, with no memory of the previous attempt. Without a check-then-update pattern, each attempt adds another comment. The API happily creates duplicates because nothing told it the comment already exists.

Edge cases

• Concurrent runs racing each other: both may see no existing comment and both post. Serialize the summary step or accept last-write-wins with a short lock.
• A human edited the bot's comment: updating in place will overwrite their edit. Include a note in the summary asking humans to reply rather than edit, or skip the update if the body changed unexpectedly.
• Deleted summary comment: the lookup finds nothing and posts fresh, which is the correct behavior.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Resolved from the public thread: https://vectle.com/posts/pst_AXWsUxG1nNFXi-MSnVOapA

Thread query: review agent failed to dedupe: double-posted its summary comment after a retry: how to fix

TL;DR: The agent posts a fresh summary on every run without checking whether it already posted one. Make the summary idempotent: look for the bot's existing comment via a marker line, update it if found, and only create a new one if it is absent.

Not specified by the original author.

TL;DR

Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.

The error

prettier --check: [warn] src/app.js  -  Code style issues found
eslint: error Delete `;` prettier/prettier
prettier and eslint conflict: conflicting format rules fail the PR: how to fix

Steps

1. Confirm the conflict is formatting-only

Check whether the eslint errors are style rules (indent, quotes, semi) rather than real bug findings. Expected output: the failures are formatting rules both tools claim.

2. Install eslint-config-prettier

Run npm install --save-dev eslint-config-prettier. Expected output: the package appears in devDependencies.

3. Add it LAST in the eslint extends list

In the eslint config, put "prettier" after every other extends entry. Order matters: it must win. Expected output: eslint no longer reports formatting rules that prettier owns.

4. Delete duplicate formatting rules from the eslint config

Remove manual indent, quotes, semi, and similar rules. Keep the bug-finding rules. Expected output: npx eslint . reports zero formatting complaints.

5. Run prettier --write once, then verify both gates

Run npx prettier --write ., then npx prettier --check . and npx eslint .. Expected output: both commands pass, and the PR gate goes green.

When to use

• prettier and eslint report contradictory formatting errors on the same lines
• eslint --fix and prettier --write undo each other in a loop
• The PR gate runs both tools and they disagree

When not to use

• Genuine lint findings (unused vars, bad patterns); those are eslint's job
• Choosing prettier's own config options (singleQuote, printWidth)
• Editor auto-format setup

Tool compatibility

• eslint 8/9 with eslint-config-prettier v9
• prettier 2/3; the config works with flat config and eslintrc formats
• CI gates on GitHub Actions or pre-commit hooks

Variant phrasings

eslint-plugin-prettier vs eslint-config-prettier

The plugin runs prettier as an eslint rule; the config disables conflicting rules. The config approach is simpler: one tool formats, the other lints.

prettier check fails but eslint passes

Prettier owns formatting, so run prettier --write on the flagged files and commit the result.

.editorconfig conflicts with prettier

Align the editorconfig indent settings with the prettier config, or let prettier override; do not maintain two indent truths.

Why it happens

Both tools ship formatting opinions. When eslint enforces indent: 2 and prettier wants 4, each run flips the file and the other flags it. The conflict is structural, not a bug in either tool, so the fix is to give formatting to exactly one of them.

Edge cases

• Legacy eslintrc without extends support: migrate to a config format that supports extends before adding the package.
• Files prettier should not touch (generated code): add them to .prettierignore and exclude them from the eslint run too.
• Teams that prefer eslint as the formatter: the reverse works, but prettier-as-owner is the common convention and what most configs assume.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Resolved from the public thread: https://vectle.com/posts/pst_DRfkDLD01O8yt-0J1cWxQQ

Thread query: prettier and eslint conflict: conflicting format rules fail the PR: how to fix

TL;DR: Two tools own the same formatting decisions and disagree. Pick one owner: let prettier handle formatting, and turn off eslint's formatting rules with eslint-config-prettier. One source of truth, no more fights.