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

SASS indented syntax support #1685

Closed
hhaidar opened this issue Jul 20, 2016 · 8 comments
Closed

SASS indented syntax support #1685

hhaidar opened this issue Jul 20, 2016 · 8 comments

Comments

@hhaidar
Copy link

@hhaidar hhaidar commented Jul 20, 2016

Has anyone successfully gotten old school SASS to work?

@Arcanemagus

This comment has been minimized.

Copy link
Contributor

@Arcanemagus Arcanemagus commented Jul 20, 2016

From #1670 (comment), it seems there isn't a PostCSS parser for it yet, as such there is no support here either.

@jeddy3

This comment has been minimized.

Copy link
Member

@jeddy3 jeddy3 commented Jul 20, 2016

@jeddy3 jeddy3 closed this Jul 20, 2016
@Grawl

This comment has been minimized.

Copy link
Contributor

@Grawl Grawl commented Oct 21, 2017

@jeddy3 why close an issue since requested feature is not implemented? I want to use Stylint for .sass too!

@jeddy3

This comment has been minimized.

Copy link
Member

@jeddy3 jeddy3 commented Oct 21, 2017

The issue is a dupe of #2486 (which is open).

Pending PR is at #2503, although it looks like it might have stalled. Any help jump-starting it would be appreciated.

@jeddy3

This comment has been minimized.

Copy link
Member

@jeddy3 jeddy3 commented Oct 21, 2017

@Grawl I forgot to say that we added a --custom-syntax flag, so you can use stylelint for .sass right now.

#2486 is about whether stylelint should add official support for .sass by bundling the postcss-sass parser, and that depends on if there are enough people interested in maintaining it. But like I said, there's nothing stopping you using the --custom-syntax flag to give .sass a go.

From the docs:

Note, however, that stylelint can provide no guarantee that core rules will work with syntaxes other than the defaults listed above.

@Grawl

This comment has been minimized.

Copy link
Contributor

@Grawl Grawl commented Oct 22, 2017

@jeddy3 thank you! just tried this and get some strange behaviour

I just installed both stylelint and postcss-sass

package.json

{
  "scripts": {
    "lint-sass": "stylelint test.sass",
    "lint-sass-specify-syntax": "stylelint test.sass --custom-syntax postcss-sass"
  },
  "devDependencies": {
    "postcss-sass": "^0.2.0",
    "stylelint": "^8.2.0"
  }
}

I created a test file with just one rule to test:

test.sass

body
	background: #000
My Stylelint config 

.stylelintrc

rules:
  at-rule-no-unknown: true
  block-no-empty: true
  color-no-invalid-hex: true
  comment-no-empty: true
  declaration-block-no-duplicate-properties:
  - true
  - ignore:
    - consecutive-duplicates-with-different-values
  declaration-block-no-shorthand-property-overrides: true
  font-family-no-duplicate-names: true
  function-calc-no-unspaced-operator: true
  keyframe-declaration-no-important: true
  media-feature-name-no-unknown: true
  no-empty-source: true
  no-extra-semicolons: true
  no-invalid-double-slash-comments: true
  selector-pseudo-class-no-unknown: true
  selector-pseudo-element-no-unknown: true
  selector-type-no-unknown: true
  shorthand-property-no-redundant-values: true
  string-no-newline: true
  unit-no-unknown: true
  at-rule-name-case: lower
  at-rule-name-space-after: always-single-line
  at-rule-semicolon-newline-after: always
  block-closing-brace-empty-line-before: never
  block-closing-brace-newline-after: always
  block-closing-brace-newline-before: always-multi-line
  block-closing-brace-space-before: always-single-line
  block-opening-brace-newline-after: always-multi-line
  block-opening-brace-space-after: always-single-line
  block-opening-brace-space-before: always
  comment-whitespace-inside: always
  custom-property-empty-line-before:
  - always
  - except:
    - after-custom-property
    - first-nested
    ignore:
    - after-comment
    - inside-single-line-block
  declaration-bang-space-after: never
  declaration-bang-space-before: always
  declaration-block-semicolon-newline-after: always-multi-line
  declaration-block-semicolon-space-after: always-single-line
  declaration-block-semicolon-space-before: never
  declaration-block-single-line-max-declarations: 1
  declaration-block-trailing-semicolon: always
  declaration-colon-newline-after: always-multi-line
  declaration-empty-line-before:
  - always
  - except:
    - after-declaration
    - first-nested
    ignore:
    - after-comment
    - inside-single-line-block
  function-comma-newline-after: always-multi-line
  function-comma-space-after: always-single-line
  function-comma-space-before: never
  function-max-empty-lines: 0
  function-parentheses-newline-inside: always-multi-line
  function-parentheses-space-inside: never-single-line
  function-whitespace-after: always
  length-zero-no-unit: true
  max-empty-lines: 1
  media-feature-name-case: lower
  media-query-list-comma-newline-after: always-multi-line
  media-query-list-comma-space-after: always-single-line
  media-query-list-comma-space-before: never
  no-eol-whitespace: true
  no-missing-end-of-source-newline: true
  number-no-trailing-zeros: true
  property-case: lower
  selector-combinator-space-before: always
  selector-descendant-combinator-no-non-space: true
  selector-list-comma-newline-after: always
  selector-list-comma-space-before: never
  selector-max-empty-lines: 0
  selector-pseudo-class-case: lower
  selector-pseudo-element-case: lower
  selector-type-case: lower
  unit-case: lower
  value-list-comma-newline-after: always-multi-line
  value-list-comma-space-after: always-single-line
  value-list-comma-space-before: never
  value-list-max-empty-lines: 0
  indentation: tab
  string-quotes: single
  no-duplicate-selectors: true
  color-named: always-where-possible
  color-no-hex: true
  selector-no-qualifying-type: true
  selector-combinator-space-after: always
  selector-attribute-quotes: always
  selector-attribute-operator-space-before: never
  selector-attribute-operator-space-after: never
  selector-attribute-brackets-space-inside: never
  declaration-no-important: true
  declaration-colon-space-before: never
  declaration-colon-space-after: always
  property-no-vendor-prefix: true
  value-no-vendor-prefix: true
  number-leading-zero: always
  function-url-quotes: always
  font-family-name-quotes: always-where-recommended
  comment-empty-line-before: never
  at-rule-no-vendor-prefix: true
  rule-empty-line-before: never
  selector-pseudo-element-colon-notation: double
  selector-pseudo-class-parentheses-space-inside: never
  selector-no-vendor-prefix: true
  media-feature-range-operator-space-before: always
  media-feature-range-operator-space-after: always
  media-feature-parentheses-space-inside: never
  media-feature-name-no-vendor-prefix: true
  media-feature-colon-space-before: never
  media-feature-colon-space-after: always
 

And script without --custom-syntax has an expected output:

➜ npm run -s lint-sass

test/one-liner.sass
 2:14  ✖  Expected "#000" to be "black"   color-named
 2:14  ✖  Unexpected hex color "#000"     color-no-hex
 2:17  ✖  Expected a trailing semicolon   declaration-block-trailing-semicolon

It looks like .sass support is included with Stylelint so I don't want to use --custom-syntax.

Moreover, using --custom-syntax postcss-sass I got more errors:

➜ npm run -s lint-sass-one-liner-specify-syntax

test/one-liner.sass
 1:4   ✖  Expected single space before "{"                    block-opening-brace-space-before
 2:14  ✖  Expected "#000" to be "black"                       color-named
 2:14  ✖  Unexpected hex color "#000"                         color-no-hex
 2:17  ✖  Expected a trailing semicolon                       declaration-block-trailing-semicolon
 2:18  ✖  Expected newline before "}" of a multi-line block   block-closing-brace-newline-before

So I think Stylelint uses different parser than postcss-sass.

I uninstalled postcss-sass and got the same output on lint-sass script.


If I add more lines in test.sass I got nothing but "Missed semicolon" warning:

body
	font: Times New Roman, Arial, sans-serif
	background: black
	color: #fff
➜ npm run -s lint-sass

test.sass
 2:32  ✖  Missed semicolon   CssSyntaxError

And different output using custom syntax:

➜ npm run -s lint-sass-specify-syntax

test.sass
 1:4   ✖  Expected single space before "{"                    block-opening-brace-space-before
 2:8   ✖  Expected quotes around "Times New Roman"            font-family-name-quotes
 4:9   ✖  Expected "#fff" to be "white"                       color-named
 4:9   ✖  Unexpected hex color "#fff"                         color-no-hex
 4:12  ✖  Expected a trailing semicolon                       declaration-block-trailing-semicolon
 4:13  ✖  Expected newline before "}" of a multi-line block   block-closing-brace-newline-before

Here's a repo to test with: https://github.com/Grawl/stylelint-sass-test

@jeddy3

This comment has been minimized.

Copy link
Member

@jeddy3 jeddy3 commented Oct 22, 2017

just tried this and get some strange behaviour

It might look strange, but it's actually all very explainable.

tl;dr Use stylelint test.sass --custom-syntax postcss-sass and only turn on rules applicable to SASS syntax.

And script without --custom-syntax has an expected output:

The default PostCSS parser (which is designed for standard CSS syntax) parsed your snippet to this AST, which accounts for the three errors you saw.

It looks like .sass support is included with Stylelint so I don't want to use --custom-syntax.

It's not. It's just the default parser attempted to parse your simple snippet and did so without a syntax error.

If I add more lines in test.sass I got nothing but "Missed semicolon" warning:

That's because the default parser failed to parse your larger snippet. Instead, it threw a syntax error.

Moreover, using --custom-syntax postcss-sass I got more errors:

In your config, you're turning on rules that check for punctuation that doesn't exist in SASS e.g. braces and semicolons via block-closing-brace-newline-before and declaration-block-trailing-semicolon respectively. Don't turn on those rules. The built-in rules are geared towards standard CSS syntax, so quite of few of the stylistic rules won't be applicable to SASS. If you decide to use stylelint-config-standard, then you'll need to turn off a bunch of the punctuation rules. (In case you're wondering, SugarSS is an alternative SASS-like syntax based on the PostCSS parser (and ecosystem)).

If you fix your config and use stylelint test.sass --custom-syntax postcss-sass, I suspect you'll just get just three violations for your larger snippet:

2:8   ✖  Expected quotes around "Times New Roman"            font-family-name-quotes
4:9   ✖  Expected "#fff" to be "white"                       color-named
4:9   ✖  Unexpected hex color "#fff"                         color-no-hex
@Grawl

This comment has been minimized.

Copy link
Contributor

@Grawl Grawl commented Oct 24, 2017

@jeddy3 thank you for such a detailed reply!

okay so we need two features:

  1. Try to prevent false-positive parsing like indented Sass one-liners
  2. Disable syntax-based rules for different parsers
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants
You can’t perform that action at this time.