HTML & CSS

Set Up an SCSS Compiler in VS Code with Dart Sass

Compile SCSS from VS Code with a pinned Dart Sass dependency, verify generated CSS, use watch mode during editing, and keep release output reproducible.

By Uddhav Gopani, FounderPublished 27 September 2026Updated 29 September 2026

Install a compiler alongside the editor

VS Code can help you edit SCSS, but syntax highlighting and completion do not themselves produce CSS. Use a Sass compiler in your project, then run it from VS Code’s terminal or a task. This guide uses Dart Sass through its official npm package, so the compiler version belongs to the project rather than to an individual editor extension.

Open the project folder in VS Code and use a terminal in that folder. You need Node.js and npm available there. If the project already has package.json, keep it and add the dependency to the existing setup. For a new empty project, create package.json before installing the compiler.

Add a pinned development dependency

npm init -y
npm install --save-dev --save-exact sass@1.105.0

Run the initialization command only when the project does not already have its package file. The version shown is the compiler used for these examples; it is not a promise that future projects should never update. Commit the package file and lockfile so collaborators can install the same dependency graph. The official Sass installation guide also documents standalone installation options.

A project-local dependency makes the compiler invocation reproducible through npm scripts. It avoids relying on whichever global sass command happens to be installed on a teammate’s machine. If the terminal cannot find npm, resolve the Node.js installation or terminal environment first; installing a syntax-highlighting extension will not solve that missing executable.

Create and compile one entry stylesheet

Create src/styles.scss with the following source. The variable is an SCSS feature, and the nested hover rule refers to the parent selector. The browser must receive the compiled CSS output, not this source file.

$accent: #1d4ed8;
$space: 8px;

.button {
  color: $accent;
  padding: $space ($space * 2);
  &:hover { text-decoration: underline; }
}

Add the following entries to the existing scripts object in package.json. Keep any other project scripts already present. The build command finishes after one compilation; the watch command remains running while you edit.

{
  "scripts": {
    "css:build": "sass --no-error-css src/styles.scss public/styles.css",
    "css:watch": "sass --watch src/styles.scss:public/styles.css"
  }
}

Run npm run css:build and inspect public/styles.css. It should contain .button with color #1d4ed8 and padding 8px 16px, followed by a .button:hover rule. The absence of the $accent variable in the generated file confirms that you inspected compiler output rather than the original SCSS.

Verify the edit-and-recompile loop

Run npm run css:watch, change $accent to #0f766e and save the source. Confirm that the output changes to the new color. Then change $space to 10px and check for padding 10px 20px. Two different edits help reveal a watcher that started successfully but is observing the wrong folder or writing to an unexpected destination.

Keep the watch terminal visible when diagnosing a problem. An invalid SCSS edit should report a compiler error. Watch-mode error output is a development aid, not a production stylesheet to publish. Stop the watcher when finished; do not configure a release job to wait forever for a process intended to remain active.

Load the output file in the page

Point the page’s stylesheet link at the URL corresponding to public/styles.css in your development server. The URL depends on which directory that server exposes; the filesystem path is not automatically the browser URL. Inspect the network response and computed button styles to confirm that the page uses the output you just generated.

If the page still shows the old color, check the requested file, cache state and competing CSS declarations before reinstalling the compiler. A successful Sass run and a stale browser response are different stages of the workflow. The VS Code CSS and SCSS documentation explains the editor’s language features separately from compiler integration.

Keep release compilation separate from manual CSS tools

Use the compiler’s compressed output option for a release when that matches your build policy, and fail the release if compilation fails. Decide whether to distribute source maps or retain them for debugging. The Dart Sass CLI reference documents those output and error-handling options.

The local CSS minifier can inspect or compact CSS after compilation. It cannot resolve SCSS variables, mixins or modules, and the site’s CSS Compiler label does not mean a Sass compiler is embedded there. Keep Dart Sass responsible for SCSS compilation and the maintained source files in the project.