Migrating away from LibSass

Help
1

Note: For the sake of completeness, I put a version of this post that has links as references for everything mentioned here on my website.

The king is (almost) dead. Long live the king!

LibSass, which undergirds Jekyll’s native Sass pre-compiler, is deprecated. Jekyll has roughly until November to transition to Dart Sass or drop native Sass support altogether.

Here’s exactly how Jekyll is affected:

  • The jekyll gem depends on the jekyll-sass-converter gem.
  • The jekyll-sass-converter gem depends on the sassc gem (also known as sassc-ruby and not to be confused with sassc, a wrapper around LibSass written in C).
  • The sassc gem, because it is a Ruby wrapper around LibSass, is among those affected by the project’s deprecation.
  • There are currently no plans for migrating the sassc gem to Dart Sass, which is the “primary” or “reference” implementation of Sass.

This is the second time, as far as I am aware, that the default Sass implementation that Jekyll was using has been deprecated. The first was when Ruby Sass died.

Ending Ruby Sass took one year and two days. The language designers announced deprecation on April 2, 2018; they declared end-of-life on April 4, 2019. This time around, the deprecation announcement of LibSass came on Oct. 26, 2020, so Oct. 28 seems like a reasonable target date for transitioning away from LibSass.

I have been scouring for references on this and trying to figure out the plans for moving on from LibSass. For myself, I am planning to jury-rig a script to compile Sass with Dart Sass, and hopefully it is as fast and easy as simply using the jekyll-sass-converter gem natively, but I have only so much patience for scripting since I prefer to instead financially support people who develop open source projects.

So, my question is: What is the Jekyll project’s plan for migrating away from LibSass? I think it would be best to maintain rather than drop Sass support and to do so by moving to Dart Sass, but I’m likely not the person who would do that programming, and I am only so tied into the weeds of the project itself.

Any and all guidance, references, opinions, or updates welcome.

2

I don’t think it is that big of a deal in the short term, and in the long run I’m sure Jekyll will be able to switch to something that uses that. Deprecated just means it won’t get new features, not that it can’t be used at all. I think it could be used indefinitely as it is now - just no new sass features implemented.

As for a script to do it, it is actually pretty easy, just needs some extra dependencies. Here is a repo I made to try out using NPM scripts to process sass, js and images which lightens the load on Jekyll. Turns out for a small site this adds a couple seconds to the build rather than saving anything so I am not using it. The same thing could be done using Gulp and that would likely be faster than Jekyll.

This is using the new Dart sass stuff.

3

I don’t know what “short term” means precisely for these purposes, and “no new Sass features” sounds pretty bad to me.

It’s true that the Sass team hasn’t set an end-of-life date for LibSass (as far as I’m aware), but it’s not too early to think about the future of Jekyll’s Sass support. I think we want to keep this project modern, and letting native support of Sass language features stagnate seems like an iffy choice. Personally, I have higher expectations for Jekyll than letting it stagnate on that kind of thing.

I will add that it is not merely that LibSass is going extinct; there is already a major rift in compatibility between Dart Sass and LibSass. My introduction to this whole issue was that I tried to use an @use statement in my Sass on my Jekyll site, and the Sass precompiler rejected it even though it’s been a language feature for a pretty long time.

I’ve browsed your repo, and I like it. Now I’m thinking about whether I want to add Amplify to my stack, but I probably won’t. And when I say that I want to “jury-rig a script to compile Sass with Dart Sass,” I mean that I want to do that with a Ruby gem that I plug directly into my Jekyll site so that updates to a Sass file triggers the updating mechanism in.

This is a philosophical choice; I support the Jekyll project and want to advance it rather than just the other big libraries it works off, so I’m cautiously optimistic that I can script a gem that is useful to others. That’s the same attitude that is why I’m implicitly lobbying we discuss a means for modernizing Jekyll’s native Sass support.

4

I’m sure it will be taken care of, and my guess is people are working on it.

This forum is mostly user support - if you want to dive into the actual project you may find more info on the actual Jekyll repo:

and it looks like you already posted in the jekyll-sass-converter repo.

I love Jekyll, but have played around with using scripts to make it faster - though the last bunch of updates have made it much faster for me so that is no longer an issue. It used to take 6-7 seconds for it to rebuild, which is great, but if you are doing css work and you can get it down to .5 seconds then that can be a lot more fun. Using Gulp to process sass,js and images did that for me back then. Then I played around with the NPM script I linked to and liked that better than Gulp until I figured out it was actually slower. I tried using Jekyll again to do it all and was happy to find it is now as fast for my (very small) sites as it was using Gulp and was way faster than the NPM scripts. Awesome! and no real dependencies.

PS - I quite like Amplify now - pretty easy to setup, moved all my sites over to it last month.

5

This seems relevant.

(Linking to the talk.jekyll forum thread instead of straight to the github thread because both threads seem relevant here – sry to make you click twice :sweat_smile:)

6

I’d love to see the entire SASS dependency be optional. For build pipelines that have to do a fresh bundle, there’s a lot of overheard currently having to compile sass. If one is not using it, there’s a bunch of wasted resources going into things.

7

I’ve used Gulp to process sass before which made jekyll significantly faster - where would the wasted overhead be? I certainly did not see that.

What about the way jekyll works makes sass processing mandatory? or maybe you are saying the dependency on a particular library to do sass processing?

8

This comment
on that issue/ thread in the sass-converter repo mentions a fork that uses DartSass.

So if you want to experiment you can.

9

jekyllbot just did an auto-reminder to update jekyll-sass-converter — maybe we can make requests for a sass update here.