root = true

[*]

indent_style = space

indent_size = 2

end_of_line = lf

charset = utf-8

trim_trailing_whitespace = true

insert_final_newline = true

[*.md]

trim_trailing_whitespace = false

env:

mocha: true

node: true

# globals:

#########################

## Only add globals if you're absolutely certain they need to be globals

##########################

# console: true

#########################

## set to 0 to allow

## set to 1 to disallow as warning

## set to 2 to disallow as error

#########################

rules:

#########################

## Optional Rules

#########################

# Disallow use of `console`

no-console: 2

# Disallow warning comments

no-warning-comments:

- 1

- terms

- todo

- fixme

location

- anywhere

# Warns when variables are defined but never used

no-unused-vars: 1

# Enforces comma style (first or last)

comma-style:

- 2

- last

# Enforces one true `this` variable

consistent-this:

- 2

- self

# Allows dangling underscores in identifiers

no-underscore-dangle: 2

# Enforces function expressions to have a name

func-names: 0

# Set maximum depth of nested callbacks

max-nested-callbacks:

- 1

- 3

#########################

## Core Rules

##########################

# Enforces camel case names

camelcase: 2

# Prohibit use of == and != in favor of === and !==

eqeqeq: 2

# Suppresses warnings about == null comparisons

no-eq-null: 2

# No mixing tabs and spaces, with 2 spaces only

no-mixed-spaces-and-tabs: 2

# Prohibits use of a variable before it is defined

no-use-before-define: 2

# Requires capitalized names for constructor functions

new-cap: 2

# Prohibits use of explicitly undeclared variables

no-undef: 2

# Enforces Use Strict at the top of function scope

strict:

- 2

- global

# Requires variable declarations to be at the top

vars-on-top: 2

# Enforce curly braces around blocks in loops and conditionals

curly: 2

# Prohibits the use of immediate function invocations w/o wrapping in parentheses

wrap-iife: 2

# Prohibits `argument.caller` and `argument.callee`

no-caller: 2

# Requires all `for in` loops to filter object's items

guard-for-in: 2

# Prohibits comparing a variable against itself

no-self-compare: 2

# Prohibits use of `undefined` variable

no-undefined: 0

# Prohibits nested ternaries

no-nested-ternary: 2

# Enforces a space before blocks

space-before-blocks:

- 2

- always

# Enforces spaces following keywords

space-after-keywords:

- 2

- always

- checkFunctionKeyword: true

# Enforces quoted property names

quote-props:

- 2

- always

# Enforces padded blocks

padded-blocks:

- 1

- never

# Enforce functions as expressions

func-style:

- 2

- expression

# Require brace style

brace-style:

- 2

- stroustrup

# Prohibits Yoda conditions

yoda:

- 2

- never

# Enforce use of single quotation marks for strings.

quotes:

- 2

- single

# Enforces space inside of brackets (except property name)

space-in-brackets:

- 2

- always

- propertyName: false

singleValue: false

- node

- iojs

**March 26, 2015**

* **New** Added `renderSync` option that can be used through `sass.sync()`

* **Change** Updated to `node-sass` 3.0.0-alpha.1

* **New** Added support for `gulp-sourcemaps` including tests

* **New** Added `.editorconfig` for development consistency

* **New** Added linting and test for said linting

* **Change** Updated the README

* **New** `logError` function to make streaming errors possible instead of breaking the stream

Gulp Sass is a very light-weight [Gulp](https://github.com/gulpjs/gulp) wrapper for [`node-sass`](https://github.com/sass/node-sass), which in turn is a Node binding for [`libsass`](https://github.com/sass/libsass), which in turn is a port of [`Sass`](https://github.com/sass/sass).

* Before creating a new issue, perform a [cursory search](https://github.com/issues?utf8=%E2%9C%93&q=repo%3Adlmanning%2Fgulp-sass+repo%3Asass%2Fnode-sass+repo%3Asass%2Flibsass+repo%3Asass%2Fsass+repo%3Asass-eyeglass%2Feyeglass) in the Gulp Sass, Node Sass, Libsass, and main Sass repos to see if a similar issue has already been submitted.

* You can create an issue [here](https://github.com/dlmanning/gulp-sass/issues). Please include as many details as possible in your report.

* Issue titles should be descriptive, explaining at the high level what it is about.

* Please include the version of `gulp-sass` you are using.

* Do not open a [pull request](#pull-requests) to resolve an issue without first receiving feedback from a `collaborator` or `owner` and having them agree on a solution forward.

* Include screenshots and animated GIFs whenever possible; they are immensely helpful.

* Issues that have a number of sub-items that need to be complete should use [task lists](https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments) to track the sub-items in the main issue comment.

* **DO NOT ISSUE A PULL REQUEST WITHOUT FIRST [SUBMITTING AN ISSUE](#submitting-issues)**

* Pull requests should reference their related issues. If the pull request closes an issue, [please reference its closing in your commit messages](https://help.github.com/articles/closing-issues-via-commit-messages/). Pull requests not referencing any issues will be closed.

* Pull request titles should be descriptive, explaining at the high level what it is doing, and should be written in the same style as [Git commit messages](#git-commit-messages).

* Update the `CHANGELOG` with the changes made by your pull request, making sure to use the proper [Emoji](#emoji-cheatsheet).

* Follow our JavaScript styleguides. Tests will fail if you do not.

* Ensure that you have [EditorConfig](http://editorconfig.org/) installed in your editor of choice and that it is functioning properly.

* Do not squash or rebase your commits when submitting a Pull Request. It makes it much harder to follow your work and make incremental changes.

* Update the [CHANGELOG](#maintaining-thechangelog) with your changes.

* Branches should be made off of the most current `master` branch from `[email protected]:dlmanning/gulp-sass.git`

* Pull requests should be made into our [master](https://github.com/dlmanning/gulp-sass/tree/master) branch.

* Use the present tense (`"Add feature"` not `"Added Feature"`)

* Use the imperative mood (`"Move cursor to…"` not `"Moves cursor to…"`)

* Limit the first line to 72 characters or less

* Consider including relevant Emoji from our [Emoji cheatsheet](#emoji-cheatsheet)

Versioning is done through [SEMVER](http://semver.org/). When creating a new version, create new release branch off of `master` with the version's name, and create a new tag with `v` prefixed with the version's name from that branch.

For instance, if you are creating version `1.1.0`, you would create a branch `release/1.1.0` from `master` and create a tag `v1.1.0` from branch `release/1.1.0`.

The Changelog should have a list of changes made for each version. They should be organized so additions come first, changes come second, and deletions come third. Version numbers should be 2nd level headers with the `v` in front (like a tag) and the date of the version's most recent update should be underneath in italics.

Changelog messages do not need to cover each individual commit made, but rather should have individual summaries of the changes made. Changelog messages should be written in the same style as [Git commit messages](#git-commit-messages).

When creating creating commits or updating the CHANGELOG, please **start** the commit message or update with one of the following applicable Emoji. Emoji should not be used at the start of issue or pull request titles.

* :art: `:art:` when improving the format/structure of the code

* :racehorse: `:racehorse:` when improving performance

* :memo: `:memo:` when writing long-form text (documentation, guidelines, principles, etc…)

* :bug: `:bug:` when fixing a bug

* :fire: `:fire:` when removing code or files

* :green_heart: `:green_heart:` when fixing the CI build

* :white_check_mark: `:white_check_mark:` when adding tests

* :lock: `:lock:` when dealing with security

* :arrow_up: `:arrow_up:` when upgrading dependencies

* :arrow_down: `:arrow_down:` when downgrading dependencies

* :shirt: `:shirt:` when removing linter warnings

* :shipit: `:shipit:` when creating a new release