New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect ternary operator in operator-linebreak rule #3274

Closed
jfsiii opened this Issue Aug 4, 2015 · 7 comments

Comments

Projects
None yet
6 participants
@jfsiii

jfsiii commented Aug 4, 2015

For example, after disallows:

foo = 1
    + 2;

but

foo = true
    ? 1
    : 2;

generates no warnings. Should this rule also match a ConditionalExpression?

@eslintbot

This comment has been minimized.

eslintbot commented Aug 4, 2015

Thanks for the issue! We get a lot of issues, so this message is automatically posted to each one to help you check that you've included all of the information we need to help you.

Reporting a bug? Please be sure to include:

  1. The version of ESLint you are using (run eslint -v)
  2. The source code that caused the problem
  3. The configuration you're using (for the rule or your entire config file)
  4. The actual ESLint output complete with line numbers

Requesting a new rule? Please be sure to include:

  1. The use case for the rule - what is it trying to prevent or flag?
  2. Whether the rule is trying to prevent an error or is purely stylistic
  3. Why you believe this rule is generic enough to be included

Requesting a feature? Please be sure to include:

  1. The problem you want to solve (don't mention the solution)
  2. Your take on the correct solution to problem

Including this information in your issue helps us to triage it and get you a response as quickly as possible.

Thanks!

@gyandeeps gyandeeps added the triage label Aug 4, 2015

@nzakas

This comment has been minimized.

Member

nzakas commented Aug 5, 2015

I can't recall, but I think this might have been intentionally omitted because people tend to put the ? and : at the front of lines even when everything else is at the end.

Anyone else recall?

@michaelficarra

This comment has been minimized.

Member

michaelficarra commented Aug 5, 2015

That sounds like good enough reason to me. I use that style myself.

@jfsiii

This comment has been minimized.

jfsiii commented Aug 5, 2015

IMO, that's a reason for choosing a default value, not a reason to prevent detection.

@nzakas

This comment has been minimized.

Member

nzakas commented Aug 5, 2015

@jfsiii can you explain more what you mean by that?

@jfsiii

This comment has been minimized.

jfsiii commented Aug 5, 2015

IMO, common usage should influence the API or defaults; not prevent the rule from working correctly (detect & enforce position of operators).

I used after in the notes, but the same issue exists for before. As written, before and after values ignore ConditionalExpressions. This allows non-compliant code styles to avoid detection.

Say one wants ? & : to start a line. Shouldn't the linter signal that

foo = true 
    ? 
    1 :
    2;

or

foo = 
      true ? 
      1 : 2;

don't match that rule?

If it's common for people to want + and most other operators after, but ? and : 'before`, the API could be adjusted to support that. Without putting too much thought in to it, something like:

// all operators at the end of the line, except `?` & `:`
"operator-linebreak": [2, "after", {
    "?": false,
    ":": false
}]

// all operators at the end of the line, except `?` & `:`
"operator-linebreak": [2, "after", ["?", ":"]]

This could even be the default behavior. For me, the specific API is less important than detecting the improperly formatted code.

@nzakas nzakas added bug rule accepted and removed triage labels Aug 6, 2015

@nzakas

This comment has been minimized.

Member

nzakas commented Aug 6, 2015

Thanks for explaining. We should definitely do something here, just not sure what yet.

BYK added a commit that referenced this issue Aug 25, 2015

@BYK BYK self-assigned this Aug 25, 2015

BYK added a commit that referenced this issue Aug 25, 2015

BYK added a commit that referenced this issue Aug 26, 2015

BYK added a commit that referenced this issue Aug 26, 2015

@nzakas nzakas closed this in #3512 Aug 26, 2015

@eslint eslint bot locked and limited conversation to collaborators Feb 7, 2018

@eslint eslint bot added the archived due to age label Feb 7, 2018

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