The Ruby Sass CLI was the original sass gem command line. This page explains how it worked (modes, styles, watch, source maps), how it differs from Dart Sass, and how to migrate—with five reference examples from the official docs.
01
Status
Deprecated / EOL
02
Modes
1:1 & many
03
--style
4 output styles
04
Watch
--watch / --update
05
Migrate
→ Dart Sass
06
Practice
5 examples
Concept
What Was the Ruby Sass CLI?
Ruby Sass shipped a sass executable (from the Ruby gem) that compiled .scss / .sass files to CSS. Like Dart Sass today, it had one-to-one and many-to-many modes, watch/update flags, and style options.
It is unmaintained—no security or language updates.
Default stdin / unknown extensions used the indented syntax (Dart Sass defaults to SCSS).
It offered four--style values; Dart Sass keeps two.
Features like --compass and --require tied it to the Ruby ecosystem.
💡
Beginner tip
If you are learning Sass in 2026, skip installing Ruby Sass. Install Dart Sass and practice with the Dart Sass CLI. Read this page when you meet an old Gemfile or Capistrano script.
Modes
📄 One-to-One Mode
terminal
sass [input.scss] [output.css]
Compiled one input to one output. No output path printed CSS to the terminal. No input or output meant read from stdin and print CSS. Extensions: .scss → SCSS, .sass → indented. Otherwise (and for stdin), indented was the default—use --scss to force SCSS.
Modes
📦 Many-to-Many Mode
Enabled when any argument contains a colon, or when --update / --watch is passed. Directory compiles skipped _partials. Unlike a pure one-shot Dart folder compile, Ruby many-to-many also behaved like an update: it compiled only when sources were newer than the CSS.
Assuming stdin is SCSS — Ruby defaulted to indented; Dart defaults to SCSS.
Copying nested/compact — not available on Dart Sass.
Keeping --compass forever — replace with modern packages / CSS.
Mixing docs — Ruby flag letters differ (-t style vs Dart -s).
Pro Tips
💡 Best Practices
✅ Do
Treat Ruby Sass as historical / migration reference
Move CI and local scripts to the Dart Sass CLI
Translate old styles to expanded or compressed
Document the migration in the repo README
Retest visual output after switching compilers
❌ Don’t
Start new projects on the Ruby gem
Depend on unmaintained Compass + Ruby Sass stacks
Ignore official EOL warnings on sass-lang.com
Assume every Ruby flag exists on Dart Sass
Leave production builds on an abandoned toolchain
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about the Ruby Sass CLI
EOL tool—understand it, then move to Dart Sass.
5
Core concepts
⚠️01
EOL
unmaintained
Status
📄02
Same modes
1:1 & many
CLI
⚙️03
4 styles
Dart keeps 2
Output
📝04
Stdin
indented default
Quirk
✓05
Migrate
→ Dart Sass
Action
❓ Frequently Asked Questions
No. Official docs: Ruby Sass has reached end of life and is totally unmaintained. Switch to Dart Sass as soon as you can.
The sass executable from the Ruby gem. It compiled .scss/.sass to CSS in one-to-one or many-to-many mode, similar in spirit to today’s Dart Sass CLI.
By extension: .scss → SCSS, .sass → indented. Stdin and unknown extensions defaulted to the indented syntax unless you passed --scss.
Four: nested (default), expanded, compact, and compressed. Dart Sass keeps expanded and compressed only.
Install Dart Sass, replace ruby sass commands with the Dart Sass CLI (often similar), update npm/CI scripts, and retest. Prefer SCSS and modern @use modules.
Only enough to read old scripts. Invest learning time in the Dart Sass CLI and current Sass language features.
Did you know?
Official Ruby Sass docs still document --debug-info, which emitted dummy @media queries for line mapping—and warn that source maps are the modern replacement. Dart Sass focuses on source maps instead.
The Ruby Sass CLI shaped how teams compiled Sass for years, but it is end-of-life. Learn its modes and flags only to migrate—then standardize on the Dart Sass CLI for every new project.