As we discussed in our recent article, Shopify has now deprecated the use of SASS files inside themes. This presents a few challenges that all Shopify developers are finding their preferred solutions to. One of the most useful features when Shopify themes supported “on the fly” SASS compilation was that you could embed liquid code inside SASS files to use variables or filters on your SASS rules.
However, now that we need to compile our SASS files externally outside of the Shopify ecosystem, what does that mean for this feature? If you take your SASS code from your Shopify theme and try to compile it locally, you will first notice that liquid code does not play nicely since it is not valid SASS. Your SASS compiler will hit an error when it encounters liquid code, preventing your file from compiling. So what can we do?
One option is to stop using liquid inside your SASS files. So, instead of setting a background image rule like this:
div { background-image: url({{ 'image.png' | asset_url }}); } |
You can instead format your URLs with the relative path to the theme’s assets directly like this
div { background-image: url('/assets/image.png'); } |
Which is an acceptable compromise.
However, you may also rely on liquid code for more complex use cases, such as injecting variables the store owner sets in the theme customizer. For example, you may need to allow the user to set the background color or text styles of a section on a page. Or you may need to use logic to determine particular styles to set in your SASS file. Losing all of this functionality would be a step backward - especially when you don’t need to.
It is still possible to retain this functionality, and we will explain how.
The first problem to work out is how to get our SASS file to compile with liquid variables inside it. The workaround for this is to leverage SASS spring interpolation. So, to revisit our background image example
div { background-image: url({{ 'image.png' | asset_url }}); } |
We change it to this
div { background-image: url(#{'{{ \'image.png\' | asset_url }}'}); } |
We wrap the liquid code with #{ }, which allows us to access the SASS file that we need to without the SASS compiler mistakenly interpreting it as a normal SASS rule. It’s essentially us telling the compiler to treat the contents of the interpolated expression as a literal string exempt from the standard SASS syntax rules. We also need to escape the single quotes on the image filename since the liquid code is also enclosed in single quotes.
The reason this works is that, as we described in our previous article when our SASS file is compiled, it is compiled into a *.css.liquid file. And you probably see where this is going, but the reason we use *.css.liquid rather than just *.css is because the *.css.liquid means that Shopify can still read our liquid code inside the compiled CSS. So, using this technique, we can still compile our SASS file while also retaining the ability to use liquid objects containing variables, filters, and so on—the best of both worlds.
A final point to note is that while this technique works for liquid objects, it does not work for liquid tags. So, trying something like this in your SASS file will not work:
{% assign foo = 'bar' %} |
This is because tags define variables, logic, and so on, but they do not output any content to the SASS file. So they are incompatible with the idea behind this approach.
But all is not lost because you can still use liquid tags - just not inside your SASS file. Instead, move them outside of the SASS file and into your theme. The liquid template is just before the line where your SASS file is included. Any variables assigned to your tags can then be referenced inside the SASS file.
For example, we could assign a font color inside a variable using some logic so that logged-in users see black text and the rest see red text. We add this liquid code to our theme “liquid file.”
{% if customer %} |
Then, inside our SASS file, we can include the textColor variable
div { color: #{'{{ textColor }}'} } |
You can still use liquid code in your SASS files; you just need to be creative and figure out new ways to achieve the same thing as local SASS compilation. This is a good starting point.