Open In App

How to print variable to the terminal in SASS ?

Last Updated : 27 Apr, 2020
Improve
Improve
Like Article
Like
Save
Share
Report

SASS has three methods of providing an output on the terminal or console of the user.

Note: The output may vary from implementation to implementation and compiler to compiler.

  • Using @error rule: When writing mixins and functions that take arguments, you usually want to ensure that those arguments have the types and formats your API expects. If they aren’t, the user needs to be notified and your mixin/function needs to stop running.

    Sass makes it easy with the @error rule, which is written @error . It prints the value of the expression (usually a string) along with a stack trace indicating how the current mixin or function was called. Once the error is printed, Sass stops compiling the stylesheet and tells whatever system is running it that an error occurred.

    Example:




    @mixin reflexive-position($property, $value) {
      @if $property != top and $property != bottom {
        @error "Property #{$property} must be either top or bottom.";
      }
      
      $top-value: if($property == bottom, initial, $value);
      $bottom-value: if($property == bottom, $value, initial);
      
      top: $top-value;
      bottom: $bottom-value;
      [dir=rtl] & {
        top: $bottom-value;
        bottom: $top-value;
      }
    }
      
    .sidebar {
      @include reflexive-position(left, 12px);
    }

    
    

    This is what the compiler will look like in Dart CSS:

    Error: "Property left must be either top or bottom."
      ?
    3 ?     @error "Property #{$property} must be either top or bottom.";
      ?     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      ?
      example.scss 3:5   reflexive-position()
      example.scss 19:3  root stylesheet
    
  • Using @warn rule: When writing mixins and functions, you may need to avoid users from passing some arguments or values. They may be passing legacy arguments that are now deprecated, or they may be calling your API in a way that is not quite optimal.
    The @warn rule is designed just for this. It’s written @warn and it prints the value of the expression (usually a string) for the user, along with a stack trace indicating how the current mixin or function was called. Unlike the @error rule, though, it doesn’t stop Sass entirely.

    Example: SASS file




    $known-properties: webkit, hd;
      
    @mixin property($character, $value, $properties) {
      @each $property in $properties {
        @if not index($known-properties, $properties) {
          @warn "Unknown property #{$property}.";
        }
      
        -#{$property}-#{$character}: $value;
      }
      #{$character}: $value;
    }
      
    .tilt {
      @include property(transform, rotate(30deg), webkit hd);
    }

    
    

    Output: CSS file

    .tilt {
      -webkit-transform: rotate(30deg);
      -hd-transform: rotate(30deg);
      transform: rotate(30deg);
    }
    

    This is what the compiler will look like in Dart CSS:

    Warning: Unknown property webkit.
        example.scss 6:7   property()
        example.scss 16:3  root stylesheet
    
  • Using @debug rule: Sometimes its useful to see the value of a variable or expression while you’re developing your stylesheet. That’s what the @debug rule is for: it’s written @debug, and it prints the value of expression, along with the filename and line number.

    Example: SASS




    @mixin inset-divider-offset($offset, $padding) {
      $divider-offset: (2 * $padding) + $offset;
      @debug "divider offset: #{$divider-offset}";
      
      margin-left: $divider-offset;
      width: calc(100% - #{$divider-offset});
    }

    
    

    This is what the compiler will look like in Dart CSS:

    test.scss:3 Debug: divider offset: 132px
    

Note: You can pass any value to @debug, not just a string! It prints the same representation of that value as the meta.inspect() function.



Like Article
Suggest improvement
Share your thoughts in the comments

Similar Reads