SASS compiler integration

[madskristensen]

SASS as in .scss files and not .sass.

All the features we have for compiling LESS files should be mirrored for SASS compilation as well. Preferably, the compiler should run on nodejs just like LESS and CoffeeScript.

VS2013 will add a SASS editor in an Update soon and WE needs to support it.

Here are the features:

• Compile on save
• Compile on build
• Menu button for solution-wide recompilation
• Options page
• Preview window (Margin)

VS takes care of:

• Content type definitions
• Editor Intellisense and validation
• File icon

These features should be started independent of the VS editor support, to make sure it's ready on time

[am11]

Nice idea! Now we have node base ready, it shouldn't be a hassle :)

Lets do it for both SASS (.sass) and SCSS (.scss). Where SASS will have indentation-wise syntax and SCSS has curly braces syntax (like LESS).

[madskristensen]

I don't think we should do anything for .sass unless it's super cheap, since there will be no editor support. Also, no one uses .sass anymore.

[am11]

Peeps who are in love with CoffeeScript (nifty syntax), do appreciate sass. Would it be possible giving basic syntax highlighting support via WE?

[am11]

We can hook node based compilers for both.

[madskristensen]

Don't you think they use Stylus instead of .sass?

[am11]

Yes and that too (also HAML, but that's beside the point) :)

Sass and Scss both supports equal syntax. Just differ in style.

[madskristensen]

My point is that I'd try to avoid adding larger features for things that less than 3% uses. I believe .sass is one of them.

I'd rather do .scss first and then see if people will ask for .sass. My gut tells me that no one will ask for the support.

[am11]

Yes, you are right. SASS is less widespread and low popularity was the main reason they introduced LESS-like scss syntax in first place. So .scss that is and we would refer it as SASS. (although I am wondering, would the name "SASS" confuse masses? as people may tend to try .sass with WE.)

[SLaks]

We can't really work on this without a ContentType definition.
Can we have a beta of the update?

[madskristensen]

No, it's still too early. I'll see what I can do though. We can add a content type definition hidden behind a #Debug flag for development.

[am11]

I am figuring out which files to keep in node_modules directory. Each package has different test folders and sometimes more folders for development environment.

[SLaks]

Note that we should do all SASS work in a separate branch so that we don't interfere with releases.

[am11]

@madskristensen, duplicate all the Less keys with Sass prefix.

[madskristensen]

No, let's keep to this branch

[SLaks]

Why?

[am11]

@madskristensen, here we go :)

[madskristensen]

@SLaks Because I'm a Git novice and I'm afraid of getting lost. Also, I foresee major merge conflicts when merging the branches

[am11]

I guess next we need to:

• hookup the extension .scss.
• adjust settings.
• do testing to fix the regex _errorParsingPattern and especially SourceMaps. (because they are also not providing a way to provide path to source maps in command line like CoffeeScript and we found a bug in their implementation: CLI: SourceMap sources path should be relative jashkenas/coffeescript#3296).

[SLaks]

And add unit tests.

[am11]

YES! I always envy people who practice TDD. But in our workflow its kind of hard, unless @madskristensen start rejecting PR with missing required tests! :D

[am11]

[UPDATED]

• CLI ouput in JSON OR any custom format sass/node-sass#206 (redirected to Prettify output CSS (with --output-style=expanded) sass/libsass#233)
• Update libsass to bring source-maps sass/node-sass#194 (redirected to CLI: Report character position in error sass/libsass#234 & CLI ouput in JSON OR any custom format sass/libsass#235)
• CLI: Incorrect ERRORLEVEL reported sass/node-sass#207 (fixed by arian/node-sass@dd7f509)

As soon as these are resolved, we will unfix the hacks / tweaks (and sourceMaps would be made functional). Currently, the sourceMaps are inline, like this:

/* line 65, C:\Users\Adeel\Documents\Visual Studio 2013\WebSites\WebSite1\1\2\3\cd.scss */
h6 {
  font-family: "Segoe UI", Frutiger, "Frutiger Linotype", "Dejavu Sans", "Helvetica Neue", Arial, sans-serif;
  font-size: 12px; }

/* line 71, C:\Users\Adeel\Documents\Visual Studio 2013\WebSites\WebSite1\1\2\3\cd.scss */
#main-nav {
  background: url('menu_background.png') repeat-x;
  min-height: 45px;
  margin-bottom: 60px; }
  /* line 76, C:\Users\Adeel\Documents\Visual Studio 2013\WebSites\WebSite1\1\2\3\cd.scss */
  #main-nav .top-bar {
    margin: 0 auto;
    background-color: transparent; }

Also, formatting is weird. I used --output-style=expanded switch and yet this is the prettiest output its generating. I guess the ROR's sass gem (the one provided with Zurb Foundation) formats the output after the compilation. Can we trigger VS's built-in CSS document formatter in post-processing method?

Here is the related issue: sass/libsass#233

@madskristensen, this can be closed now. 8-)