Skip to content
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

Rule-idea:space-around-operator #20

Closed
alexander-akait opened this issue May 3, 2016 · 11 comments
Closed

Rule-idea:space-around-operator #20

alexander-akait opened this issue May 3, 2016 · 11 comments
Assignees
Milestone

Comments

@alexander-akait
Copy link
Contributor

https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md#spacearoundoperator

@kristerkari
Copy link
Collaborator

Thanks! I guess this could be useful for someone, so I'll add this to the next milestone.

@kristerkari kristerkari added this to the 1.1.0 milestone May 3, 2016
@jeddy3
Copy link
Collaborator

jeddy3 commented May 19, 2016

Perhaps called calculation-no-unspaced-operator as "calculation" seems to be a thing in SCSS) so it can be used in tandem with stylelint's core rule?

@kristerkari kristerkari modified the milestones: Next, 1.1.0 May 31, 2016
@dryoma
Copy link
Collaborator

dryoma commented Jun 16, 2016

@jeddy sure, no problem.

As about the rule. I am goint to make it exactly a -no- rule, meaning prohibiting spaces around operators seems to be no-go. At least because $var--lol is a valid variable name in Sass, and if we disallow spaces we will force users to write $var - 10px as $var-10px, which would lead to a totally incorrect result.

I'd also save ourselves an effort distinguishing calc from all the other functions and would rather check operators inside calc() here as well.

@jeddy3
Copy link
Collaborator

jeddy3 commented Jun 16, 2016

I am goint to make it exactly a -no- rule

I agree. Well reasoned.

@alexander-akait
Copy link
Contributor Author

i think best options: "always" and "never".

@dryoma
Copy link
Collaborator

dryoma commented Jun 16, 2016

@evilebottnawi with "never" users won't be able to write operations like $var - 10px; they will be forced to write it as $var-10px, which Sass interprets as a variable name (like in $var-10px: #faaac0;)

@alexander-akait
Copy link
Contributor Author

@dryoma oops, i forget ;) right rule must have no

@dryoma dryoma self-assigned this Jun 17, 2016
@dryoma
Copy link
Collaborator

dryoma commented Jun 23, 2016

Some more things I'd like to bring up:

  1. Make operator rather than calculation the thing here, as the rule would work with conditions and logical operations (@if ($i == 10 and $j != 1)) as well.

  2. Users (me included) would want control over where newlines are allowed: before or after an operator. Yet I think it's best to do it in a way of eslint's operator-linebreak. I.e. not forcing linebreaks on every instance of an operator, but just specifying where they are allowed (before of after the operator) if a used wants to set them. Also, no distinguishing on whether it is a multiline operation (just like function-calc-no-unspaced-operator doesn't do it).

    So I'm thinking of a set of rules:

    • operator-no-unspaced - require a single whitespace on both sides of an operator;
    • operator-no-empty-line-before - disallow empty line before an operator;
    • operator-no-empty-line-after - disallow empty line after an operator;
  3. (A question to @jeddy3 ) I just noticed that this config (styleling v6.5.1)

    "function-comma-newline-after": "always-multi-line",
    "indentation": 2

    Allows this code:

    background: rgba(10,
    11,
    1,
    0.1);

    i.e., doesn't require additional level of indentation for function arguments on separate lines. Does each rule need to address indentation itself?

@jeddy3
Copy link
Collaborator

jeddy3 commented Jun 23, 2016

Does each rule need to address indentation itself?

Nope, indentation should be the sole domain of the indentation rule.

Originally the indentation rule just ignored the indentation within function arguments and other parentheses. Now there is an option to check. We put it behind an option to avoid requiring a major release. With 7.0 on the horizon this behaviour might change.

Make operator rather than calculation the thing here

That looks elegant and well-reasoned to me.

@dryoma
Copy link
Collaborator

dryoma commented Jun 23, 2016

Wow, totally missed those options, thanks!

@kristerkari kristerkari modified the milestones: Next, 1.2.0 Jun 24, 2016
dryoma added a commit that referenced this issue Jul 10, 2016
dryoma added a commit that referenced this issue Jul 10, 2016
dryoma added a commit that referenced this issue Jul 10, 2016
@dryoma
Copy link
Collaborator

dryoma commented Jul 26, 2016

Published with 1.3.0.

@dryoma dryoma closed this as completed Jul 26, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

5 participants
@jeddy3 @kristerkari @alexander-akait @dryoma and others