A Node-only Sass linter for both sass and scss syntax!
You can get sass-lint from NPM:
npm install sass-lint --save-dev
Sass-lint can be configured from a .sass-lint.yml file in your project. If you don't have one in the root of your project or you would like all your projects to follow a standard config file then you can specify the path to one in your project's package.json file.
For example:
{
"name": "my-project",
"version": "1.0.0",
"sasslintConfig": "PATH/TO/YOUR/CONFIG/FILE"
}Use the Sample Config as a guide to create your own .sass-lint.yml config file. The default configuration can be found here.
Migrating from SCSS-Lint: If you already have a config for SCSS-Lint, you can instantly convert it to the equivalent Sass Lint config at sasstools.github.io/make-sass-lint-config.
The following are options that you can use to config the Sass Linter.
- cache-config - Allows you to cache your config for a small speed boost when not changing the contents of your config file
- config-file - Specify another config file to load
- formatter - Choose the format for any warnings/errors to be displayed
- merge-default-rules - Allows you to merge your rules with the default config file included with sass-lint
- output-file - Choose to write the linters output to a file
The files option can either be set to a glob or it can be set to an object, where the key include is set to the glob you want to include, and ignore set to either a glob string or an array of glob strings that you would like to ignore.
files:
include: 'sass/**/*.s+(a|c)ss'
ignore:
- 'sass/vendor/**/*.*'For all rules, setting their severity to 0 turns it off, setting to 1 sets it as a warning (something that should not be committed in), and setting to 2 sets it to an error (something that should not be written). If a rule is set to just a severity, it will use the default configuration (where available).
If you want to configure options, set the rule to an array, where the first item in the array is the severity, and the second item in the array is an object including the options you would like to set.
An example configuration of a rule with options look like the following:
indentation:
- 2
-
size: 2Sass Lint v1.1.0 introduced the ability to run Sass Lint through a command line interface. See the CLI Docs for full documentation on how to use the CLI.
There are small differences which are useful to understand over other CLI tools you may have encountered with other linters.
By default any rule set to severity: 2 in your config will throw an error which will stop the CLI on the first error it encounters. If you wish to see a list of errors and not have the CLI exit then you'll need to use the -q or --no-exit flag.
Warnings or any rule set to severity: 1 in your config by default will not be reported by the CLI tool unless you use verbose flag -v or --verbose.
With this in mind if you would like to have the CLI show both warnings and errors then at the very least your starting point to use the cli should be the following command.
sass-lint -v -q
Below is an example of the command being used to load a config -c app/config/.sass-lint.yml file, show errors and warnings on the command line, and target a glob pattern **/*.scss:
sass-lint -c app/config/.sass-lint.yml '**/*.scss' -v -q
or with long form flags
sass-lint --config app/config/.sass-lint.yml '**/*.scss' --verbose --no-exit
To add a list of files to ignore tests/**/*.scss, dist/other.scss into the mix you could do the following:
sass-lint -c app/config/.sass-lint.yml '**/*.scss' -v -q -i 'tests/**/*.scss, dist/other.scss'
or with long form flags
sass-lint --config app/config/.sass-lint.yml '**/*.scss' --verbose --no-exit --ignore 'tests/**/*.scss, dist/other.scss'
Notice that glob patterns need to be wrapped in quotation or single quote marks in order to be passed to sass-lint correctly and if you want to ignore multiple paths you also need to wrap it in quotation marks and seperate each pattern/file with a comma and a space
,.
This will be revisited and updated in sass-lint v2.0.0.
For further information you can visit our CLI documentation linked below.
We welcome all contributions to this project but please do read our contribution guidelines first, especially before opening a pull request. It would also be good to read our code of conduct.
Please don't feel hurt or embarrassed if you find your issues/PR's that don't follow these guidelines closed as it can be a very time consuming process managing the quantity of issues and PR's we receive. If you have any questions just ask!
Our AST is Gonzales-PE. Each rule will be passed the full AST which they can traverse as they please. There are many different node types that may be traversed, and an extensive API for working with nodes. The file of the rule must have the same name as the name of the rule. All of the available rules are in our rules directory. Default options will be merged in with user config.