-
Notifications
You must be signed in to change notification settings - Fork 463
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
Support for sass-script maps data-type? #263
Comments
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. |
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 ( You can install it with |
+1, would love to see the map data-type built-in in Libsass. Here is the latest documentation about it: |
This feature would be amazing for me. How quickly does this libsass adopt new features after released in Sass 3.3? |
Really want to use susy. Is libsass supposed to be up to date with the latest sass version? |
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. |
I'm sorry, but because of that reason I went back to using compass.
|
I am afraid that I might have to jump ship too. |
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. |
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. |
Why not just use compass, it is not as fast, granted, but it just plain
|
Having to install ruby just to compile css is too much on my CI server.
|
Maybe someone could design a "compiles with libsass" badge for devs to add to their readme.
|
Ruby is extremely light, you'll be fine.
|
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.
|
+1 for a 'compiles with libsass' badge, this would be a good incentive. |
@lunelson thank you for sass-list-maps! 👍 🍻 |
@digitaljhelms glad to help. |
@digitaljhelms @lunelson did you get susy working with the sass-list-maps polyfill ? |
I haven't used Susy. |
+1 for a 'compiles with libsass' badge |
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. |
@thomaswelton that would be badass indeed. |
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. |
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. |
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? |
@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 |
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. |
+1 can't compile https://github.com/thoughtbot/bourbon without it |
+1 |
@kuraga just "npm i node-bourbon" |
+1 |
1 similar comment
+1 |
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. |
With the |
Yup, I believe so. |
This was a big deal, thanks @xzyfer! |
Happy to help |
+1 for support sass-script maps |
@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: On a side note Susy 2.2.2.alpha.1 does support LibSass now. |
@ogbaoghene Libsass 3.1.0 has full maps and If you use node-sass the 2.0.0-beta has Libsass 3.1.0. |
@designorant @xzyfer Updating |
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).
The text was updated successfully, but these errors were encountered: