Update: Added auto-fix to multiline-ternary #12982

Sawtaytoes · 2020-02-28T17:03:56Z

Prerequisites checklist

I have read the contributing guidelines.
The team has reached consensus on the changes proposed in this pull request. If not, I understand that the evaluation process will begin with this pull request and won't be merged until the team has reached consensus.

What is the purpose of this pull request? (put an "X" next to an item)

[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[X] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[ ] Other, please explain:

What changes did you make? (Give an overview)

Added functionality to automatically fix multiline-ternary issues.

Is there anything you'd like reviewers to focus on?

While it may seem like doing '\n? ' is opinionated, I did have changed to make this take a new option and either put the ? on the previous line or next line. This is actually unnecessary because operator-linebreak handles it for you.

This will most-likely have to be reflected in the docs as well similar to how indent is required for every rule's ability to properly fix tabbing.

kaicataldo · 2020-02-28T19:48:07Z

Thanks for contributing. Just so you're aware, since there isn't an accepted issue for this, we'll be starting the consensus-seeking process outlined here. This can take some time, so we ask for your patience.

It's fine to wait to implement them until the team has decided whether or not we will accept this, but we also require corresponding tests for any changes in the codebase.

Sawtaytoes · 2020-02-28T19:55:58Z

@kaicataldo Of course! I'll make sure to add tests as well :).

mdjermanovic · 2020-03-02T14:46:19Z

I support this enhancement 👍

Wondering was there a specific reason why this rule isn't already fixable, almost all other whitespace rules are.

Sawtaytoes · 2020-03-02T17:57:18Z

@kaicataldo
I wanted to clarify the part about there not being an existing issue.

The reason I made this PR is actually because I had an issue with ternary auto-formatting. Without auto-fixing multiline-ternary, operator-linebreak does not work properly. I noticed ? being on the end of the line where I required it be in the front.

So even though operator-linebreak auto-fixes, it only does so with the "before" configuration when multiline-ternary is providing this line-break functionality.

'operator-linebreak': [
  'warn',
  'before',
],

mdjermanovic · 2020-03-03T01:06:50Z

The reason I made this PR is actually because I had an issue with ternary auto-formatting. Without auto-fixing multiline-ternary, operator-linebreak does not work properly. I noticed ? being on the end of the line where I required it be in the front.

Can you please provide an example where this happens?

Sawtaytoes · 2020-03-03T05:20:08Z

@mdjermanovic

Came across this same code with different variable names in a project at work. This isn't the only instance, but it's a recurring example.

items = isSomething ? [
  ...stuff,
  ...moreStuff,
] : collection.items

Nothing happens even though the ? and : should drop down a line. If I put in the multiline-ternary adjustment, then it looks like this:

items = isSomething
  ? [
    ...stuff,
    ...moreStuff,
  ]
  : collection.items

^^ It's indenting the ternary like that because of indent.

The only rule change between these is multiline-ternary (default of always).

operator-linebreak, for whatever reason, doesn't error in this situation. Once you start messing with linebreaks for ? and :, it works great!

Sawtaytoes · 2020-03-03T05:25:56Z

It's now passing all unit tests with output props.

The output results are a little wonky, but they work correctly if you use it together with indent and operator-linebreak. If operator-linebreak wasn't required, it'd require duplicating its functionality in multiline-ternary since you'd need to know which side to put the ? and : when line-breaking.

I updated the docs to reflect this factor.

I noticed unfixed warnings from this ESLint rule and wanted to auto-fix them. While it may seem like doing `'\n? '` is opinionated, I did have changed to make this take a new option and either put the `?` on the previous line or next line. This is actually unnecessary because `operator-linebreak` handles it for you.

yeonjuan · 2020-03-17T12:03:45Z

👍 I agreed with this enhancement.

kaicataldo · 2020-03-17T17:52:12Z

It looks like we just need a champion to accept this.

aladdin-add · 2020-04-04T14:32:47Z

it is accepted now! 🎉

mdjermanovic · 2020-04-15T18:07:27Z

docs/rules/multiline-ternary.md

+### --fix
+
+If this rule is invoked with the command-line `--fix` option, it's recommended to define both `indent` and `operator-linebreak` if you want to have sensible results when using the `always` and `always-multiline` options.


I'm not sure if this documentation update is necessary.

The same applies to a lot of fixable rules, but we usually don't have these sections since it's reasonable to expect that other formatting rules are also enabled and configured. operator-linebreak is already listed in "Related Rules".

This detailed explanation with examples is certainly useful, but it's also an additional thing to maintain and keep in sync with other rules.

Thoughts from the team?

mdjermanovic · 2020-04-15T20:23:11Z

lib/rules/multiline-ternary.js

+                                const testToken = astUtils.isParenthesised(sourceCode, node.test)
+                                    ? sourceCode.getTokenAfter(node.test)
+                                    : node.test;
+
+                                const consequentToken = astUtils.isParenthesised(sourceCode, node.consequent)
+                                    ? sourceCode.getTokenBefore(node.consequent)
+                                    : node.consequent;


This would produce invalid autofix for a code with multiple parentheses around any of the operands, for example:

/* eslint multiline-ternary: ["error", "never"] */ ((a)) ? b : c;

will be autofixed to:

/* eslint multiline-ternary: ["error", "never"] */ ((a) ? b : c;

Maybe we could slightly change the logic, to something like how operator-linebreak finds these tokens.

(the same applies to if (!areConsequentAndAlternateOnSameLine))

mdjermanovic · 2020-04-15T20:41:55Z

lib/rules/multiline-ternary.js

+                                    fixer.replaceTextRange(
+                                        [
+                                            testToken.range[1],
+                                            consequentToken.range[0]
+                                        ],
+                                        " ? "


This can remove comments, for example:

/* eslint multiline-ternary: ["error", "never"] */ a ? // comment b : c;

will be autofixed to:

/* eslint multiline-ternary: ["error", "never"] */ a ? b : c;

In my opinion, for this particular rule it would be fine to not autofix code (return null) if there are any comments within the range between the two tokens.

(the same applies to if (!areConsequentAndAlternateOnSameLine)).

mdjermanovic · 2020-04-15T21:15:16Z

lib/rules/multiline-ternary.js

+                                return (
+                                    fixer.replaceTextRange(
+                                        [
+                                            testToken.range[1],
+                                            consequentToken.range[0]
+                                        ],
+                                        "\n? "
+                                    )


Maybe we could just insert \n before ? instead of replacing the range? I believe all other newline rules work that way.

(the same applies to if (areConsequentAndAlternateOnSameLine))

mdjermanovic · 2020-04-18T06:02:15Z

#13195 might be relevant to this.

kaicataldo · 2020-05-14T18:56:14Z

@Sawtaytoes Anything else we can do to help you land this?

Sawtaytoes · 2020-05-14T22:45:04Z

Hey, I can take a look again this weekend and see what needs done.

Sawtaytoes · 2020-05-21T08:54:10Z

Sadly, I didn't have time last weekend.

mdjermanovic · 2020-05-30T01:58:30Z

#13367 changes how this rule works (a bit), and adds some code that might be helpful for this, so maybe we could merge #13367 first and then continue with this PR on top of those changes?

nzakas · 2020-06-11T18:40:55Z

It looks like #13367 has been merged.

@Sawtaytoes can you rebase onto master?

mdjermanovic · 2020-09-18T21:45:11Z

@Sawtaytoes it would be great to have this feature, is there anything we can do to help?

Sawtaytoes · 2020-09-19T02:03:46Z

@mdjermanovic If you wanna pair code, that'd be great. At this point, it's been so long I'd need to refresh myself on what I was even doing, how I tested, etc.

I had a second kid since I made the original PR, so I haven't had as much time to spend in off-work coding. But if I had someone to pair with, I'm sure we could figure it out, write up any remaining requirements for someone else to pick up (or me), and get this merged!

vegerot · 2020-12-21T19:11:53Z

What else needs to be done to get this merged in?

nzakas · 2020-12-23T01:53:36Z

@vegerot it looks like we would need someone to take over this PR to get it moving again.

mdjermanovic · 2020-12-23T03:47:35Z

This should be easier with the current version of this rule. All relevant tokens are already there, and there's no need to check for parentheses.

eslint/lib/rules/multiline-ternary.js

Lines 50 to 57 in 145aec1

    
           const questionToken = sourceCode.getTokenAfter(node.test, astUtils.isNotClosingParenToken); 
        
           const colonToken = sourceCode.getTokenAfter(node.consequent, astUtils.isNotClosingParenToken); 
        
           const firstTokenOfTest = sourceCode.getFirstToken(node); 
        
           const lastTokenOfTest = sourceCode.getTokenBefore(questionToken); 
        
           const firstTokenOfConsequent = sourceCode.getTokenAfter(questionToken); 
        
           const lastTokenOfConsequent = sourceCode.getTokenBefore(colonToken); 
        
           const firstTokenOfAlternate = sourceCode.getTokenAfter(colonToken);

It's fine to just return null if there are any comments within the range that should be fixed.

Documentation update doesn't seem necessary.

aladdin-add · 2020-12-23T07:15:53Z

ha, thanks @mdjermanovic pointing! I can take over and update it later.

eslint-deprecated bot added the triage An ESLint team member will look at this issue soon label Feb 28, 2020

Sawtaytoes force-pushed the patch-2 branch from a00ffc6 to a0f221e Compare March 2, 2020 23:26

Sawtaytoes force-pushed the patch-2 branch from a0f221e to 7724edb Compare March 3, 2020 05:13

Sawtaytoes force-pushed the patch-2 branch from 7724edb to 5638b2f Compare March 3, 2020 05:48

aladdin-add self-assigned this Apr 4, 2020

aladdin-add added accepted There is consensus among the team that this change meets the criteria for inclusion and removed evaluating The team will evaluate this issue to decide whether it meets the criteria for inclusion labels Apr 4, 2020

kaicataldo changed the title ~~Added auto-fix to multiline-ternary~~ Update: Added auto-fix to multiline-ternary Apr 4, 2020

mdjermanovic reviewed Apr 15, 2020

View reviewed changes

mdjermanovic requested changes Apr 15, 2020

View reviewed changes

mdjermanovic mentioned this pull request Sep 18, 2020

multiline-ternary doesn't check parentheses #13195

Closed

aladdin-add mentioned this pull request Dec 26, 2020

Update: add autofix to rule multiline-ternary #13958

Merged

1 task

aladdin-add closed this Jan 1, 2021

eslint-github-bot bot locked and limited conversation to collaborators Jul 1, 2021

eslint-github-bot bot added the archived due to age This issue has been archived; please open a new issue for any further discussion label Jul 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update: Added auto-fix to multiline-ternary #12982

Update: Added auto-fix to multiline-ternary #12982

Sawtaytoes commented Feb 28, 2020 •

edited

kaicataldo commented Feb 28, 2020

Sawtaytoes commented Feb 28, 2020

mdjermanovic commented Mar 2, 2020

Sawtaytoes commented Mar 2, 2020 •

edited

mdjermanovic commented Mar 3, 2020

Sawtaytoes commented Mar 3, 2020 •

edited

Sawtaytoes commented Mar 3, 2020 •

edited

yeonjuan commented Mar 17, 2020

kaicataldo commented Mar 17, 2020

aladdin-add commented Apr 4, 2020

mdjermanovic Apr 15, 2020

mdjermanovic Apr 15, 2020

mdjermanovic Apr 15, 2020

mdjermanovic Apr 15, 2020

mdjermanovic commented Apr 18, 2020

kaicataldo commented May 14, 2020

Sawtaytoes commented May 14, 2020

Sawtaytoes commented May 21, 2020 •

edited

mdjermanovic commented May 30, 2020

nzakas commented Jun 11, 2020

mdjermanovic commented Sep 18, 2020

Sawtaytoes commented Sep 19, 2020

vegerot commented Dec 21, 2020

nzakas commented Dec 23, 2020

mdjermanovic commented Dec 23, 2020

aladdin-add commented Dec 23, 2020

		### --fix

		If this rule is invoked with the command-line `--fix` option, it's recommended to define both `indent` and `operator-linebreak` if you want to have sensible results when using the `always` and `always-multiline` options.

Update: Added auto-fix to multiline-ternary #12982

Update: Added auto-fix to multiline-ternary #12982

Conversation

Sawtaytoes commented Feb 28, 2020 • edited

Prerequisites checklist

What is the purpose of this pull request? (put an "X" next to an item)

What changes did you make? (Give an overview)

Is there anything you'd like reviewers to focus on?

kaicataldo commented Feb 28, 2020

Sawtaytoes commented Feb 28, 2020

mdjermanovic commented Mar 2, 2020

Sawtaytoes commented Mar 2, 2020 • edited

mdjermanovic commented Mar 3, 2020

Sawtaytoes commented Mar 3, 2020 • edited

Sawtaytoes commented Mar 3, 2020 • edited

yeonjuan commented Mar 17, 2020

kaicataldo commented Mar 17, 2020

aladdin-add commented Apr 4, 2020

mdjermanovic Apr 15, 2020

Choose a reason for hiding this comment

mdjermanovic Apr 15, 2020

Choose a reason for hiding this comment

mdjermanovic Apr 15, 2020

Choose a reason for hiding this comment

mdjermanovic Apr 15, 2020

Choose a reason for hiding this comment

mdjermanovic commented Apr 18, 2020

kaicataldo commented May 14, 2020

Sawtaytoes commented May 14, 2020

Sawtaytoes commented May 21, 2020 • edited

mdjermanovic commented May 30, 2020

nzakas commented Jun 11, 2020

mdjermanovic commented Sep 18, 2020

Sawtaytoes commented Sep 19, 2020

vegerot commented Dec 21, 2020

nzakas commented Dec 23, 2020

mdjermanovic commented Dec 23, 2020

aladdin-add commented Dec 23, 2020

Sawtaytoes commented Feb 28, 2020 •

edited

Sawtaytoes commented Mar 2, 2020 •

edited

Sawtaytoes commented Mar 3, 2020 •

edited

Sawtaytoes commented Mar 3, 2020 •

edited

Sawtaytoes commented May 21, 2020 •

edited