coderaiser / putout-editor / 36327993525

100%

push

github

feature: plugin-putout-editor: remove-duplicated-receiver, the rule the fixer should have been

`a && a.b()` evaluates `a` twice. It is only safe when `a` is a plain read, and after the
optional-chaining conversion it usually was not: getState() && getState().value runs the
store getter twice, and two reads can disagree.

That code came out of `putout . --fix`, not out of a person. `convert-optional-to-logical`
turns `a?.b()` into `a && a.b()` and has no way to know the receiver was a call, so it
duplicates the evaluation silently. Twenty-nine tsc errors later I had bound every one by
hand - which is exactly the work a rule should be doing, and did not.

The matcher fires only when the receiver CONTAINS a call, so `q.r && q.r.s()` and
`p && p.toString()` are left alone. Reading a property is not a side effect, and a rule
flagging those would be noise - it is why the first cut, which tested only
isIdentifier(__a), was too broad to be worth having. Verified by planting real code in
packages/client/src and watching putout . find it:

  1:17  error  Bind the left side to a local: && calls it twice

Zero hits on the repository as it stands, which is the point: the 29 are already fixed, so
this is a guard for the next `?.` expansion rather than a report on the present. A rule with
no current violations is cheap; the same code arriving again in 60 files is not.

Report-only, so replace maps the pattern to itself and the file comes back byte for byte.
@putout/test told me the better API for that - `t.transform` on an identical pair fails with
"use noTransform()", so the test is `t.noTransform`, and that in turn means no -fix fixture,
which is the convention putout-style.md records: a fixture a transform asserts on has a twin,
a fixture a not* asserts on does not.

Also off for README.md, where the anti-pattern is the documentation. The rule caught its own
README on the first run, which is the fence-is-real-javascript trap doing its job again.

26 tests, 100% ... (continued)

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