0.0
No commit activity in last 3 years
No release in over 3 years
Automatically checks SCSS style with scss-lint when files are modified.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 1.3
< 5.0, >= 4.2.3
~> 10.0
~> 3.0
~> 0.20
~> 0.3
~> 0.7

Runtime

~> 2.0
~> 0.30.0
 Project Readme

Dependency Status Build Status Coverage Status Code Climate

guard-scss-lint

guard-scss-lint automatically checks your SCSS code style with scss-lint when files are modified.

Tested on MRI 1.9, 2.0, 2.1, JRuby in 1.9 mode and Rubinius.

Installation

Please make sure to have Guard installed before continue.

Add guard-scss-lint to your Gemfile:

group :development do
  gem 'guard-scss-lint'
end

and then execute:

$ bundle install

or install it yourself as:

$ gem install guard-scss-lint

Add the default Guard::ScssLint definition to your Guardfile by running:

$ guard init scsslint

Usage

Please read the Guard usage documentation.

Options

You can pass some options in Guardfile like the following example:

guard :scsslint, all_on_start: false do
  # ...
end

Available Options

all_on_start: true     # Check all files at Guard startup.
                       #   default: true
cli: '--some-opts'     # Pass arbitrary scss-lint CLI arguments.
                       # An array or string is acceptable.
                       #   default: nil
hide_stdout: false     # Do not display console output (in case outputting to file).
                       #   default: false
keep_failed: true      # Keep failed files until they pass.
                       #   default: true
notification: :failed  # Display Growl notification after each run.
                       #   true    - Always notify
                       #   false   - Never notify
                       #   :failed - Notify only when failed
                       #   default: :failed

Advanced Tips

If you're using a testing Guard plugin such as guard-rspec together with guard-scss-lint in the TDD way (the red-green-refactor cycle), you might be uncomfortable with the offense reports from scss-lint in the red-green phase:

  • In the red-green phase, you're not necessarily required to write clean code – you just focus writing code to pass the test. It means, in this phase, guard-rspec should be run but guard-scss-lint should not.
  • In the refactor phase, you're required to make the code clean while keeping the test passing. In this phase, both guard-rspec and guard-scss-lint should be run.

In this case, you may think the following Guardfile structure useful:

# This group allows to skip running scss-lint when RSpec failed.
group :red_green_refactor, halt_on_fail: true do
  guard :rspec do
    # ...
  end

  guard :scsslint do
    # ...
  end
end

Note: You need to use guard-rspec 4.2.3 or later due to a bug where it unintentionally fails when there are no spec files to be run.

Contributing

  1. Fork it
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

MIT License

See the LICENSE.txt for details.

Credits

Yuji Nakayama's gem guard-rubocop made this project possible amidst my numerous time constraints.