How to Build Sass by Using Bazel

[[sass]] [[Bazel]]

P.S. I assume that you know what is Bazel. This blog is based on Bazel 4.2.2.

In web frontend area, CSS(Cascading Style Sheet) is the only style language that web browser know. CSS language is a low level language that hard to write. So someone create a higher level language: Sass^[1], which be able to generate css code.

This solution is called: "CSS preprocessor". In addition to being implemented using Sass, it can also be implemented using LESS, etc.

This blog introduce how to build Sass code to be CSS code by Bazel.

Why We Use Bazel

There are so many method to build Sass, why we use Bazel? Although, in essentially, Bazel build Sass code by sass native compile tool.

The reasons for using Bazel are as follows:

1. 1. It supports incremental builds: to avoid unnecessary build speed costs in the future.

2. 2. Mono repo friendly: because it support poly-language, so we can put backend's code, frontend's code, infrastructure's code, etc. into the same repo.

3. 3. Unified build tools: to achieve a high degree of consistency in build logic across the project to avoid the cost of inconsistent build logic in the future.

The Structure of Example Project

[workspace]/
    WORKSPACE
    hello_world/
        BUILD
        main.scss
    shared/
        BUILD
        _fonts.scss
        _colors.scss

Declare External Dependency in WORKSPACE File

We must declare the rule rules_sass in WORKSPACE file:

git_repository(  
    name = "io_bazel_rules_sass",  
    # the commit what you like to point
    commit = "354793d0603dbe26232f4a5fb25e67e0e9e4c909", 
    remote = "https://github.com/bazelbuild/rules_sass.git",  
)

# Setup Bazel NodeJS rules.
# See: https://bazelbuild.github.io/rules_nodejs/install.html.

# Setup repositories which are needed for the Sass rules.
load("@io_bazel_rules_sass//:defs.bzl", "sass_repositories")
sass_repositories()

The code will clone rules_sass repo with a specific commit.

You will get failed message when you build it:

ERROR: Failed to load Starlark extension '@build_bazel_rules_nodejs//:index.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @build_bazel_rules_nodejs
This could either mean you have to add the '@build_bazel_rules_nodejs' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: cycles detected during target parsing

Because the rule rules_sass dependent on the rule rules_nodejs. We can fix it by declaring the rule rules_nodejs before rules_sass had be:

http_archive(  
    name = "build_bazel_rules_nodejs",  
    sha256 = "c077680a307eb88f3e62b0b662c2e9c6315319385bc8c637a861ffdbed8ca247",  
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/5.1.0/rules_nodejs-5.1.0.tar.gz"],  
)  
  
load("@build_bazel_rules_nodejs//:repositories.bzl", "build_bazel_rules_nodejs_dependencies")  
  
build_bazel_rules_nodejs_dependencies()  
  
load("@rules_nodejs//nodejs:repositories.bzl", "nodejs_register_toolchains")  
load("@rules_nodejs//nodejs:yarn_repositories.bzl", "yarn_repositories")  
  
nodejs_register_toolchains(  
    name = "nodejs",  
    node_version = "16.13.2",  
)  
  
yarn_repositories(  
    name = "yarn",  
    yarn_version = "1.22.17",  
)

# rules_sass's declaration here

NOTE: It's a good practice that to avoid conflict with other rules by declaring explicitly the rule rules_nodejs in WORKSPACE file.

Declare Bazel Target in BUILD File

In this example project, we declared 2 sass libraries in shared/BUILD file:

package(default_visibility = ["//visibility:public"])

load("@io_bazel_rules_sass//:defs.bzl", "sass_library")

sass_library(
    name = "colors",
    srcs = ["_colors.scss"],
)

sass_library(
    name = "fonts",
    srcs = ["_fonts.scss"],
)

In hello_world/BUILD file, we declared a sass_binary target to output css file:

package(default_visibility = ["//visibility:public"])

load("@io_bazel_rules_sass//:defs.bzl", "sass_binary")

sass_binary(
    name = "hello_world",
    src = "main.scss",
    deps = [
         "//shared:colors",
         "//shared:fonts",
    ],
)

sass_binary has many attributes, like:

• • output_dir: the directory path where the css output.

• • output_name：the file name of css output.

Please go to the Github repo to get more attribute's info.

main.scss

In the main.scss file, we need to note that in @import, the import is the name of the sass_library, not the real file name with an underscore:

@import "shared/fonts"; 
@import "shared/colors";

html {
  body {
    font-family: $default-font-stack;
    h1 {
      font-family: $modern-font-stack;
      color: $example-red;
    }
  }
}

Bazel build

$ bazel build //hello_world
INFO: Found 1 target...
Target //hello_world:hello_world up-to-date:
  bazel-bin/hello_world/hello_world.css
  bazel-bin/hello_world/hello_world.css.map
INFO: Elapsed time: 1.911s, Critical Path: 0.01s

Costs

Building Sass with Bazel is not without costs. For example, migration costs for old projects, learning costs for front-end developers, etc. You need to make trade-offs based on the realities of your project.

[1] Sass: https://sass-lang.com/