Sass @warn prints a message and stack trace without stopping compilation. This page covers syntax, deprecation warnings, soft validation, how @warn differs from @error and @debug, and five compiled examples.
01
Warn
@warn
02
Continue
CSS still ships
03
Deprecate
Legacy args
04
Trace
Call stack
05
Vs error
Soft vs hard
06
Practice
5 examples
Concept
What Is @warn?
Official docs: when writing mixins and functions, you may want to discourage users from passing certain arguments or values. They may be passing legacy arguments that are now deprecated, or calling your API in a way that is not quite optimal.
The @warn rule is written @warn <expression>. It prints the value (usually a string) plus a stack trace showing how the current mixin or function was called. Unlike @error, it does not stop Sass entirely.
Warnings appear in the compiler / terminal / build log—not in the CSS file.
Compilation continues, so CSS is still produced.
Ideal for deprecations, typos you still handle, and soft API tips.
Message format and stack traces vary by Sass implementation.
💡
Beginner tip
Think of @warn as a yellow caution light: “this still works, but you should fix it.” Use @error when the light should turn red and stop the build.
Warn inside the branch that detects the problem, then continue with a sensible fallback or the original behavior so existing stylesheets keep compiling.
Output
📤 Messages & Stack Traces
Official docs: the exact format of the warning and stack trace varies from implementation to implementation. In Dart Sass it often looks like this:
WARNING: Unknown theme color `neon`. Falling back to primary.
warn-theme.scss 10:5 theme-color()
warn-theme.scss 22:3 root stylesheet
How It Works
accent resolves normally. neon warns and uses primary so the page still has a color.
Example 5 — Deprecated Function Alias
Keep an old name working while steering callers to the new one.
styles.scss
@function fg($args...) {
@warn "The fg() function is deprecated. Call foreground() instead.";
@return foreground($args...);
}
@function foreground($color) {
@return $color;
}
.title {
color: fg(#222);
}
📤 Compiled CSS:
.title {
color: #222;
}
⚠️ Compiler warning (CSS still produced):
WARNING: The fg() function is deprecated. Call foreground() instead.
warn-alias.scss 2:3 fg()
warn-alias.scss 11:10 root stylesheet
How It Works
$args... forwards every argument to foreground(). Callers keep working while the warning pushes migration.
Applications
🚀 Real-World Use Cases
API migrations — deprecate old argument names with a remap.
Design-system releases — warn before removing a token in the next major.
Typo detection — unknown prefixes or theme keys that still compile.
Alias shims — keep fg() while promoting foreground().
CI visibility — surface warnings in build logs without failing (unless you treat warnings as errors).
🧠 How Compilation Works
1
Call a mixin/function
Someone passes a legacy, odd, or mistyped argument.
Source
2
Hit @warn
Sass prints the message and a short stack trace.
Warn
3
Keep going
Your code remaps, falls back, or continues as written.
Continue
4
✓
CSS ships
Styles emit; the warning stays in the build log.
Watch Out
⚠️ Common Pitfalls
Using @warn for fatal mistakes — if CSS would be wrong, use @error.
Vague messages — always say what to use instead.
Warning spam — avoid warning on every loop iteration when one summary is enough.
Assuming users see warnings — some CI setups hide or ignore them.
Forever deprecations — plan a timeline to remove the old path.
Pro Tips
💡 Best Practices
✅ Do
Warn + remap during API migrations
Include the bad value and the recommended fix
Prefer one clear warning per call site issue
Graduate hard breaks to @error in a later major
Keep aliases thin: warn, then call the real API
❌ Don’t
Use @warn when the build must fail
Hide broken output behind soft warnings forever
Write warnings without a migration path
Confuse @warn with @debug for temporary prints
Assume warnings appear in the CSS file
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about Sass @warn
Soft guidance with a stack trace—compilation keeps going.
5
Core concepts
📝01
Warn
@warn message
Soft
🔀02
Continue
CSS still emits
Build
📤03
Guide
got vs preferred
Message
📈04
Migrate
deprecate + remap
API
✓05
Choose
warn ≠ error
Soft
❓ Frequently Asked Questions
It prints the value of an expression (usually a string) plus a stack trace for the user, but unlike @error it does not stop Sass from compiling the stylesheet.
Use it to discourage legacy or suboptimal arguments, flag typos that you still handle, announce deprecations, or guide callers without breaking their build.
@warn continues compilation and still emits CSS. @error aborts the compile. Prefer @error when continuing would produce broken output.
No. Warnings go to the compiler / terminal / build log. The CSS may still include whatever styles your mixin emitted after the warning.
Build tools and Sass CLIs often have quiet or fatal-warning options. Exact flags depend on your Sass version and bundler—check Dart Sass docs for --quiet and related options.
No. Soft warnings are for recoverable cases. If the API cannot continue safely, use @error instead.
Did you know?
Official Sass docs designed @warn specifically so library authors can discourage legacy or suboptimal arguments without breaking every consumer’s build overnight.
@warn is your soft signal for Sass APIs: print a clear message, keep compiling, and give callers time to migrate. Reserve @error for cases where continuing would ship broken CSS.