coderaiser / putout-editor / 36330218232

100%

push

github

refactor: plugin-putout-editor: remove-duplicated-receiver bites instead of reporting

The rule was report-only, with "which binding to introduce is a human call" as the reason.
That is the eslint posture, and it is the posture this package exists to replace: a tool
that tells you what to do has not done anything.

It fixes now. A declaration whose initialiser is the duplicated `&&` is split, the
receiver is bound once above it, and the guard is the scope:

  const value = getState().workbench && getState().workbench.code;
  ->
  const {workbench} = getState();
  const value = workbench && workbench.code;

Destructuring rather than a plain binding, because putout's own apply-object wanted it
one message later and the two rules would have fought otherwise.

Two bugs the fixture caught that a report never would have. The name was taken from the
receiver's callee when the receiver was a bare call, so `f() && f().deep` produced
`const f = f();` - a temporal dead zone self-reference that throws on the first line. The
name is now always a property, which cannot collide with a callee. And receiverOf assumed
the right side was either a member or a member call, so the rule crashed on its OWN source
when putout . reached it - which is why the repo-wide lint is the check and not the
plugin's own suite.

One case is reported and not fixed, on purpose: an arrow body is an expression and has
nowhere to put a statement. Rewriting it into a block body would work, but that is a larger
rewrite than the defect deserves, and a fixer that reaches past the problem is how a lint
gets switched off. Reported, not skipped, so the gap is loud - the lesson of the issue
filed two commits ago, applied here first.

28 tests, 100% coverage on all four metrics, putout clean repo-wide, tsc clean.

1081 of 1081 branches covered (100.0%)

Branch coverage included in aggregate %.

6663 of 6663 relevant lines covered (100.0%)

61.54 hits per line