Fix LinterRegistry.extract_linters_from

This wasn't working because we weren't properly scoping the constant
lookup to the `Linter` namespace. We didn't catch this in the specs
because the specs were declaring their one-off classes without any
namespaces, so they _appeared_ to be correct.

The solution was to scope the `const_get` lookup to the `Linter`
namespace, and update the specs to actually create linters in the
`SCSSLint::Linter` namespace.

Fixes #13

Change-Id: I07719f4b457b1d8886784fcefb93ae1660ad82fc
Reviewed-on: https://gerrit.causes.com/22079
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Kim Douglas Clarence Mason <kim.mason@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Bump version to 0.6.7

Change-Id: I228fe0c09c5da463fa2828337c9789740bdbedf0
Reviewed-on: https://gerrit.causes.com/22080
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add support for interpolation to SingleLinePerSelectorLinter

Previously, the `SingleLinePerSelectorLinter` would choke on
interpolated strings. This has been fixed by implementing a more
comprehensive check that properly deals with Sass::Script::Nodes in a
rule's comma sequence.

In the process of doing so, support was also added for not reporting a
lint when a selector in a multi-line rule had a comment on the end of
it, e.g.

    .foo, // A comment
    .bar {
    }

This invalid reporting was fixed by normalizing the whitespace appearing
around newline characters in the rule, since there were extra whitespace
characters being left behind when the Sass parser automatically removed
the comments from the parse tree. This fixes #10.

Change-Id: I300ce8a8fc5672c86585f375ff861b9ed50bc1f3
Reviewed-on: https://gerrit.causes.com/22121
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Teach scss-lint that `border: 0` > `border: none`

Since these two styles are behaviorally equivalent, the shorter is
preferred.

Change-Id: I1fdebdbd2180b40959472eeb123f20c42ad5307b
Reviewed-on: https://gerrit.causes.com/22669
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Teach scss-lint BorderZeroLinter about border-side

This linter originally only complained about `border: none;`. Now it
complains also about `border-top: none;` and its ilk.

Change-Id: I5969c0cf4d47aa3d229326225b8b2a1fa04a5eb1
Reviewed-on: https://gerrit.causes.com/22772
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Add variable name lint

This lint complains about underscores and capital letters in variable
names.

Related Story:
  http://www.pivotaltracker.com/story/show/50417091
  ("Add lint for underscores in variable names, mixin names,
  placeholders, and function names")

Change-Id: Ia3d5bdc40b3a6b5a8b6b2b6fd4fdf9ffee731f0e
Reviewed-on: https://gerrit.causes.com/22801
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Adam Olsen <adam.olsen@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Flesh out the readme

I just linked to scss-lint on Hacker News:

  https://news.ycombinator.com/item?id=5785885

and realized that the README doesn't really do a good job of telling
people the details of what it does (short of reading the source code or
trying it out).

This commit adds some text describing the rationale of the tool (ie.
that it is opinionated, and that consistency is more important than the
superficial details) and a list of some of the lints that are included.

As a bonus, includes a link to overcommit, which is related.

Change-Id: I5ac859b01bc9a495420bb92f160819553211b483
Reviewed-on: https://gerrit.causes.com/23023
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Tested-by: Greg Hurrell <greg@causes.com>
Add MIT license

Fixes #17.

Change-Id: I6cd14472aee8e837134d6e230f5122ae3ece90d2
Reviewed-on: https://gerrit.causes.com/23024
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Aiden Scandella <aiden@causes.com>
Add Requirements section to README

Since scss-lint has a hard dependency on using Ruby 1.9, we should make
it clear that this is a requirement. Additionally, state that only Sass
3 syntax is supported.

This addresses the concerns raised in #16.

Change-Id: I4e00ab287077ac0d5be33c81e4e2a21bfdcdc58f
Reviewed-on: https://gerrit.causes.com/23057
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Kim Douglas Clarence Mason <kim.mason@causes.com>
Use Engine filename in add_lint

In preparation for a commit that adds support for traversing
`Sass::Script::Node`s on top of `Sass::Tree::Node`s, the dependency on
fetching the filename corresponding to the lint from the node must be
removed, since `Sass::Script::Node` instances do not have a `filename`
method.

Since the engine will have the filename passed in, use that instead.

Change-Id: I6040f69e997d59755b608cc6e3d22699f0014f80
Reviewed-on: https://gerrit.causes.com/23137
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Lint names of mixin and function declarations

Previously, only variable declaration names were linted to ensure they
were lowercase and hyphenated. Change this to also lint mixin and
function declarations.

This removes the old `VariableNameLinter` and replaces it with the
improved `DeclaredNameLinter`.

Closes #8.

Change-Id: Icf250cdf1ac79ea4022a0c13635444d9cf020095
Reviewed-on: https://gerrit.causes.com/23138
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Fix ShorthandLinter to work with Sass script

Previously, the shorthand checker would incorrectly report a lint for a
property declaration like the following:

    padding: (10px / 12px) (15px / 12px);

This was because the regex was simply pulling out "10px 12px 15px 12px"
and assuming that the repeated "12px" could be shortened. However, in
this case the lint is incorrect.

The solution is to check whether or not we're dealing with a
Sass::Script::String, or a Sass::Script::List, and handle the two cases
differently. The Sass::Script::String case works as before, but the
Sass::Script::List case needs to individually call `to_sass` on each of
the items in the list and compare them to each other, rather than
calling `to_sass` on the list itself. This way expressions like:

    padding: $content-padding $content-padding;

...or...

    padding: (10px / 12px) 5px (10px / 12px);

...are correctly marked as lints, as we're comparing whole expressions
in the list.

Fixes #12

Change-Id: I90e6cd655d968e82b5f51900ee0ad00d4faa6daa
Reviewed-on: https://gerrit.causes.com/23139
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Fix PropertyFormatLinter to handle interpolation

Previously, the `PropertyFormatLinter` would incorrectly report lints
for situations such as:

    margin-#{$side}: $value;

This was due to the fact that the regex was hard-coded to assume there
were only alphabetical characters and hyphens in the property name.

To fix this, we adjust the regex to support ignoring interpolation
characters.

Fixes #5 and #15.

Change-Id: Ifbdb73a955b8a9e687f129f10b3c1fa7d42d7490
Reviewed-on: https://gerrit.causes.com/23140
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add support for traversing Sass::Script::Nodes

The implementation of the Sass parser involves two different kinds of
parse trees: ones composed of `Sass::Tree::Node`s and ones composed of
`Sass::Script::Node`s. The `Sass::Tree::Node` hierarchy encodes the
structure of SCSS documents, whereas the `Sass::Script::Node` captures
the parse tree of various Sass script throughout the document (e.g.
variables, string interpolation, argument lists, etc).

Unfortunately, this architecture means there is no built-in support to
have a visitor visit both types of nodes--only `Sass::Tree::Node`s
support visitors.

In order to give us greater flexibility in the kind of lints we can
write, we need to monkey-patch the Sass parse tree hierarchy to support
traversal over both tree and script nodes.

The net result is that lints can now define methods like
`visit_script_variable` or `visit_script_list` to easily find lints
for those kinds of nodes.

Change-Id: I60797e3748ddb5926674e750cc184da109a23cc0
Reviewed-on: https://gerrit.causes.com/23141
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Add support for linting referenced names

Previously, only _declarations_ of variables, functions, and mixins
names were linted. Now that we can traverse `Sass::Script` parse trees,
add support for linting references to variables, functions, and mixins
as well.

Change-Id: I58fafade6910033fb25c2eda5d38ba299a77c1ac
Reviewed-on: https://gerrit.causes.com/23142
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Rename EOS Heredocs to CSS

Heredocs can be given a useful description, so use `CSS` instead of the
vague `EOS`.

Change-Id: I768496c24fb95567bd18b145e05b3274e417f30b
Reviewed-on: https://gerrit.causes.com/23143
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
Use `described_class` in all specs

This is a convenient shorthand for RSpec tests, so we should use it in
the interest of keeping tests concise and DRY.

Change-Id: I6cbb510b38bafe24fb249355338dcbffe64083e4
Reviewed-on: https://gerrit.causes.com/23144
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>
DRY up specs with custom matcher

A vast majority of specs for scss-lint test the linters themselves,
which usually consist of checking whether or not a linter reported a
lint, and which line the lint was on. This involves so much duplicate
code that it was prime for DRYing up with a custom matcher.

This adds a `report_lint` custom matcher and updates all specs to use
that matcher, resulting in a lot of duplicated code being removed.

Closes #18

Change-Id: I5fa1713397f42a73a952d85b33b117fb990196bd
Reviewed-on: https://gerrit.causes.com/23172
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Consolidate linter test setup code

Each of the linter tests did the exact same thing, namely:

  * Initialize a parse tree with the CSS for the given example
  * Run the linter against that parse tree

Since linter tests will always have this format, we can DRY up this
setup code by moving it into the spec_helper file as a global `before`
hook.

By checking within the hook whether the current `described_class` is a
subclass of linter, we can dynamically choose whether to perform the
linter setup or not.

Change-Id: I7a8af2c4be6fb4abd02cd0518b2768853e18c7c8
Reviewed-on: https://gerrit.causes.com/23173
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Greg Hurrell <greg@causes.com>
Fix hex color linter to work in Sass script

The hex linter worked in situations where the hex color appeared as the
value of a property declaration, e.g.

    p {
      color: #112233; // Lint reported
    }

However, it would not work in situations where the hex color appeared as
arguments to a function or mixin, e.g.

   p {
     @include some-mixin(#112233); // Should report lint, but doesn't
   }

Even with the new support for traversing the Sass script parse tree, we
still can't fix this because the parser normalizes colors it encounters,
so we don't have access to the original characters that were written.

The only solution is to then do a line-by-line regex check for hex
colors (i.e. ignoring the parse tree) and report lints that way.

Fixes #7

Change-Id: Ib0e7ddddc221bc00a3b3677f3bc78d8e89d50f45
Reviewed-on: https://gerrit.causes.com/23185
Tested-by: jenkins <jenkins@causes.com>
Reviewed-by: Shane da Silva <shane@causes.com>