libsass choice

[glat]

By using libsass to compile SCSS file we've these problems:

1. libsass does not implement full SASS 3.3 specifications;
2. libsass has several bugs;
3. as you stated in other issues of this project when libsass gets an error it throws an exception and you can't get the real error description, and we get "compilation error", without any helpful description;
4. after several modifications on SCSS file I get a "compilation error" whatever I write in the SCSS file but the same file compiles again after VS restart. I think it's related to the previous point and the node.js web service compilation;

So, isn't easier to install Ruby and the real SASS compiler and use it in Web Essentials? I understand that libsass is a project who needs to grow up, but we need a robust SASS support and libsass isn't it.

My suggestion is to let the user choose if use the Ruby SASS compiler or the libsass.

Thanks for your work

[am11]

Here are some notes:

• We don't have ruby runtime support in WE.
• Libsass received tons of fixes and v3.3 support in past months, but the real culprit is node-sass, which is a node.js wrapper for libsass which Web Essentials uses .
  • Apparently the node-sass' repository maintainer has quit: https://twitter.com/teabass/status/494993372252495874 and nobody is accepting PRs and/or responding to bugs actively.

The opinion I share: directly use libsass! It's super swift and lighter than the whole bulky ruby-runtime and naturally lighter than its wrapper: node-sass. And it is actively maintained by so many cool C++ folks out there. This is overall the second best thing in SASS world (after ruby version).

[glat]

That twit is only of some days ago. Problem I listed is not related to that because latest commits include latest libsass version. That will only increase problems in future. As you state, furthermore, libsass is second to ruby, so, direct libsass implementation is welcome, but I prefere to give user the ability to use the installed ruby framework (WE should not install it, just use it, if any) and only if user wants as an option.

Thanks for your work

[JBowness]

All the unhelpful "Something went wrong reaching: http://127.0.0.1:13343/?service=SCSS" exceptions really throw a monkeywrench in the workflow. I'd LOVE to see some movement on this issue. A more helpful build process combined with scss mapping support for Browser Link would be amazing.

[am11]

"Something went wrong reaching" will be reduced.. almost go away! unless if your FS mess up or something. The experience would be as dandy as LESS.

When? See: sass/node-sass#378 (comment). Coming Soon™ :)

Its not like WE is the only victim here. It effects gulp/grunt guys as well as the node.js guys who are using node-sass.. and there is a big community out there for that as well.

Also, since SASS organization is taking libsass seriously too and there are announcements on Twitter that the next major release of libsass (which is in beta if you checkout their releases) would be quite promising for specs v3.3+; we may not be needing the ruby version at all. Since both ruby-sass and libsass share test-beds and the idea is to make things consistent. If C++ is your strong suit, you may also contribute by adding couple of lang features.. But at this very point, ruby sass and libsass both are not complying fully with sass specs (https://github.com/sass/sass-spec). So libsass has it strengths over ruby sass as well..

Note: I am not opposing the OP's idea. It's just there were some major issues with node-sass <-> libsass wiring, which was a major ordeal (which has been fixed). I agree that its pretty much doable thing to check for the installed Ruby runtime and take an alternative path for compilation. I am quite willing to participate in that gig too! Probably @SLaks can lay down a better architecture for that, like node-server (#381). We might be isolating the compilers from WE's core in future and we might need to wait for this feature request until then.

---

Browser link:

I think it should be working right away?

The idea is, if it works for LESS, CoffeeScript et el. then it should be working for SASS. Last time I tried it with bundle. I don't know if you have less/scss and then the output is bundled and the bundled output is used in browser, any change made in browser should be sync back. But if you minify it, it won't work with CSS-preprocessors. For JS ones; CoffeeScript and SweetJS (livescript is yet to add source-map feature), we have min's source-maps too. Its because we are using AjaxMin, which is yet to support CSS' source-maps. It has been proposed to use other tools for minifying CSS. Checkout WE's uservoice and issue tracker search..

No minification:

If it is not working and LESS is; then it might be due to the source-map issue. See sass/libsass#324. Notice, in this case even ruby-sass is not even emitting the quality source-maps, but they are certainly far much better than libsass'. Once that issue is addressed like LESS way, this will make libsass in better position than ruby-sass. :)

_{Disclaimer, I personally love Ruby! It used to be a main programming lang at my day job for a long time.}

[JBowness]

Thanks for the reply! I'll definitely be eagerly awaiting updates to libsass/node-sass then!

regarding Browser Link:

The SCSS map is recognized in my browser debugger -- it correctly displays the imported scss source. Once I make edits in the browser, Browser Link sends the changes back to the (not-minified) compiled CSS.

Once a change is made:

[am11]

Does same thing happen with LESS, if you test it against test.less? If so, that would probably mean browser link itself is not quite there yet.. (link through hierarchal sources)

Also please test both less and sass with IE11's F12DT (which supports V3 source-maps).

[JBowness]

Oh funny. It actually IS updating the underlying LESS files, but I guess because the map isn't up to date anymore, it just shows the compiled stylesheet.css referenced?

However the same thing with SCSS causes browserlink to try to update the compiled css file directly (I believe.. It actually hangs my Visual Studio IDE until I kill the browser possibly due to the size of the css, I'm not quite sure).

[am11]

With current nightly build of WE, a lot has improved in terms of SASS support (due to libsass/node-sass). And forthcoming nightlies will bring tons of more improvements (with node-sass and libsass pacing up).

ICYMI; there were lot of cool announcements in SassConf this month, libsass was also a focal point. See their roadmap here: sass/libsass#521 (bridging gaps and so forth).

@JBowness, currently there are some issues with source-map in both libsass and ruby-sass (well TBH, more issues in libsass' source-maps than ruby-sass). But the issue that compiled CSS is updating instead of the source looks weird at first glace. But I guess it's "browser link" itself being smart here; if it can't map to the source via source-map, it falls back to make change in the compiled code (which imo is an OK reaction). It's still related to sass/libsass#324. Hopefully, it will be sorted out soon. Fingers crossed!

[am11]

@SLaks, for the issue described here: npm/npm#3697 (comment), we can replace node-sass with @darrenkopp's libsass-net, as libsass-net is up-to-date with libsass tagged released (same as node-sass). We can include it as a submodule (or nuget package?) and maximize performance for libsass use-cases.

Now, we also have ruby-sass.

To recapitulate; libsass for ultimate performance benefits, while ruby-sass for edge language support.

With Update4 RTM, vNext of WE would be released. Many folks would be unhappy if node-sass issue is left unresolved. :)