Support for sass-script maps data-type?

[danielbaars]

I'm trying to compile grid system Susy Next with libsass but every few lines it throws up an "error: error reading values after ..." message. I'm told this is because libsass does not support the sass-script maps data-type (yet).

[kennethormandy]

This isn’t a super specific answer, but I remember finding there was a lot more than just that which didn’t working with Suzy Next. The last version I had working was, I think 1.0.9, and I still had to comment a mixin out.

If you’re interested in a workaround, Harp implicitly compiles SCSS files through Node-sass and libsass, and I got that version of Susy to work with it. We were testing out using Component and Harp, so you can follow the instructions for using Harp and Susy here. If you’re not interested in Harp, that fork of Susy might still prove useful for use with libsass in the meantime.

[lunelson]

I've written a library of functions that provide all the Sass 3.3 map capabilities using lists. It's 'forward-compatible'. Meaning, when native maps arrive your code will work the same. You can modify Susy Next to work with these functions by just removing the colons (:) from the maps.

You can install it with bower install sass-list-maps or cut and paste. Read more here:

Sass List-Maps

[emagnier]

+1, would love to see the map data-type built-in in Libsass.

Here is the latest documentation about it: https://github.com/nex3/sass/blob/master/doc-src/SASS_CHANGELOG.md#sassscript-maps

[aeharding]

This feature would be amazing for me. How quickly does this libsass adopt new features after released in Sass 3.3?

[thomaswelton]

Really want to use susy. Is libsass supposed to be up to date with the latest sass version?

[lunelson]

No, libsass is a several steps behind and does not support the complete set of features even from sass 3.2. If you choose to work with libsass you have to test all your output. The speed increase can make it worthwhile however.

[ljearwood]

I'm sorry, but because of that reason I went back to using compass. On Mar 13, 2014 7:24 AM, "Thomas Welton" notifications@github.com wrote:

Really want to use susy. Is libsass supposed to be up to date with the latest sass version?

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37526717 .

[nicetransition]

I am afraid that I might have to jump ship too.

[thomaswelton]

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

[nicetransition]

Very true -- I'm looking for a solution to be used in the next week. "jumping ship" is extreme, but for the time being I'm going back to compass. I will continue following the issues, pushes, releases until all the parts that I use are covered.

[ljearwood]

Why not just use compass, it is not as fast, granted, but it just plain works. On Mar 13, 2014 4:02 PM, "Thomas Welton" notifications@github.com wrote:

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37586368 .

[thomaswelton]

Having to install ruby just to compile css is too much on my CI server. Node does lots of stuff form me with gulp/grunt so I have that installed. Ruby doesn't do anything else for me and want to cut it out of my stack. Plus it's much slower in comparison.

On 13 Mar 2014, at 21:19, ljearwood notifications@github.com wrote:

Why not just use compass, it is not as fast, granted, but it just plain works. On Mar 13, 2014 4:02 PM, "Thomas Welton" notifications@github.com wrote:

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37586368 .

— Reply to this email directly or view it on GitHub.

[thomaswelton]

Maybe someone could design a "compiles with libsass" badge for devs to add to their readme. Everyone loves readme badges :)

On 13 Mar 2014, at 21:19, ljearwood notifications@github.com wrote:

Why not just use compass, it is not as fast, granted, but it just plain works. On Mar 13, 2014 4:02 PM, "Thomas Welton" notifications@github.com wrote:

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37586368 .

— Reply to this email directly or view it on GitHub.

[ljearwood]

Ruby is extremely light, you'll be fine. On Mar 13, 2014 4:35 PM, "Thomas Welton" notifications@github.com wrote:

Having to install ruby just to compile css is too much on my CI server. Node does lots of stuff form me with gulp/grunt so I have that installed. Ruby doesn't do anything else for me and want to cut it out of my stack. Plus it's much slower in comparison.

On 13 Mar 2014, at 21:19, ljearwood notifications@github.com wrote:

Why not just use compass, it is not as fast, granted, but it just plain works. On Mar 13, 2014 4:02 PM, "Thomas Welton" notifications@github.com wrote:

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

Reply to this email directly or view it on GitHub< https://github.com/hcatlin/libsass/issues/263#issuecomment-37586368> .

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37589838 .

[thomaswelton]

I've been there are done it. Not relying on ruby to do my css is a lot better than when I did use it. But this isn't about ruby. It's about libsass being faster and devs needing to support it.

On 13 Mar 2014, at 21:36, ljearwood notifications@github.com wrote:

Ruby is extremely light, you'll be fine. On Mar 13, 2014 4:35 PM, "Thomas Welton" notifications@github.com wrote:

Having to install ruby just to compile css is too much on my CI server. Node does lots of stuff form me with gulp/grunt so I have that installed. Ruby doesn't do anything else for me and want to cut it out of my stack. Plus it's much slower in comparison.

On 13 Mar 2014, at 21:19, ljearwood notifications@github.com wrote:

Why not just use compass, it is not as fast, granted, but it just plain works. On Mar 13, 2014 4:02 PM, "Thomas Welton" notifications@github.com wrote:

libsass is significantly better. Instead of jumping ship we should be pestering scss package developers to test their code against libsass. And how off adding the new sass features until libsass can catch up. I'm not sure of all the new stuff in sass 3.2 yet, but I'm sure the authors of susy could have written their plugin to work with libsass if they had thought it was a big enough priority. So instead of using susy for my grid I'm using zurb foundation as that compiles with libsass.

Reply to this email directly or view it on GitHub< https://github.com/hcatlin/libsass/issues/263#issuecomment-37586368> .

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com/hcatlin/libsass/issues/263#issuecomment-37589838 .

— Reply to this email directly or view it on GitHub.

[lunelson]

+1 for a 'compiles with libsass' badge, this would be a good incentive.

[digitaljhelms]

@lunelson thank you for sass-list-maps! :+1: :beers:

[lunelson]

@digitaljhelms glad to help.

[steffenmllr]

@digitaljhelms @lunelson did you get susy working with the sass-list-maps polyfill ?

[digitaljhelms]

I haven't used Susy.

[itanex]

+1 for a 'compiles with libsass' badge

[thomaswelton]

How bad ass would it be if I wrote a micro travis style site that would run compilation tests on new commits and pull requests to allow devs to continue using the normal SCSS compiler but run CI tests against libsass. I think that'd be pretty bad ass. :smile:

[lunelson]

@thomaswelton that would be badass indeed.

[msikma]

Would be very grateful if maps were implemented, since I'm using them in the framework I'm building and am considering switching to libsass. I guess I can try to work around the limitation, but I'd prefer not to.

[darkwebdev]

The problem with susy is that the old version that uses sass 3.2 also needs compass and the new version that doesn't need compass requires sass 3.3 and maps.

So I just keep using compass and susy on old projects and use libsass with bourbon and neat on new ones. And in general: no ruby = no crossplatform-and-version-problems.

[laurelnaiad]

I don't think the issue is developers forgetting to or not bothering to test against libsass... the issue is that they want/need features that are part of Ruby SASS and not (or not yet) in libsass. No amount of testing will cause them to change the decision to use those features if it is intentionally made.

That said, I'm all for the testing of sass code with libsass. I think a travis-like site to run tests of any sass code against libsass already exists -- travis itself is already capable of this, no?

[lunelson]

@stu-salsbury I'd be interested to know if such a tool exists and how to use it; I used to run tests in sassmeister or else hack a local save-on-change thing with Sublime Text 3 which updates the CSS file on changes. You could also hack Takana for a live-compiling setup.

@darkwebdev and @msikma if maps support is all that's holding you back try my sass-list-maps polyfill, the implementation is functionally the same. Unfortunately susy makes heavy use of Sass 3.3+ syntactical changes which do not provide new or different functionality but an alternate way of writing it, so porting Susy to libsass even with the polyfill is a bit tedious

[laurelnaiad]

It should be the case that you could set up a build script in node using something like gulp or grunt that executes node-sass against your sass files and evaluated the results using a testing framework. Hook that repository up to travis and you're in business. It will install your node npm devDependencies (of which node-sass would be one) as part of its install of your repo..... I am not familiar with how C++ repos are tested but I expect that if you wanted to test against libasss built from source (or even just straight compiled libsass with a C++ harness), that roughly the same technique would work. I suppose that if you wanted to test libsass without the risk of hitting any node-sass issues along the way this would be a better, still doable route to go.

[kuraga]

+1 can't compile https://github.com/thoughtbot/bourbon without it

[ogbaoghene]

+1

[darkwebdev]

@kuraga just "npm i node-bourbon"

[Goltergaul]

+1

[hutber]

+1

[HamptonMakes]

This has been completed by @xzyfer!

The entire initial specification for maps has been implemented. What isn't currently there is the each iterator, but that was added as a separate feature to Sass and will be treated the same here.

[lunelson]

With the @each operator thing, do you mean the multi-assignment thing like @each $key, $value in $map? That's the only thing missing?

[HamptonMakes]

Yup, I believe so.

[msikma]

This was a big deal, thanks @xzyfer!

[xzyfer]

Happy to help

[coxrichuk]

+1 for support sass-script maps

[ogbaoghene]

@hcatlin Really appreciate this, thanks a lot to @xzyfer. What's the plan for the @each operator though, is it something in the works?

[designorant]

@ogbaoghene It's already baked in in LibSass 3.1.

If you're having issues, make sure you're using the latest version of either: libsass/node-sass/gulp-sass/grunt-sass. You may also need to do some light refactoring/cleaning up to get rid of some workarounds.

On a side note Susy 2.2.2.alpha.1 does support LibSass now.

[xzyfer]

@ogbaoghene Libsass 3.1.0 has full maps and @each support. Please use http://sassmeister.com/ to verify your use case works. Feel free to open specific issues if you encounter bugs.

If you use node-sass the 2.0.0-beta has Libsass 3.1.0.

[ogbaoghene]

@designorant @xzyfer Updating grunt-sass fixed, glad no more workarounds. Thanks a lot