├── .editorconfig
├── .travis.yml
├── CONTRIBUTING.md
├── README.md
└── ruleset.xml


/.editorconfig:
--------------------------------------------------------------------------------
 1 | # editorconfig.org
 2 | 
 3 | root = true
 4 | 
 5 | [*]
 6 | indent_style = space
 7 | indent_size = 2
 8 | end_of_line = lf
 9 | charset = utf-8
10 | trim_trailing_whitespace = true
11 | insert_final_newline = true
12 | 


--------------------------------------------------------------------------------
/.travis.yml:
--------------------------------------------------------------------------------
 1 | sudo: false
 2 | language: php
 3 | php:
 4 |   - nightly
 5 |   - 5.6
 6 |   - 5.5
 7 |   - 5.4
 8 |   - hhvm
 9 | 
10 | matrix:
11 |   allow_failures:
12 |     - php: nightly
13 | 
14 | install:
15 |   - composer self-update && composer --version
16 |   - export PATH="$HOME/.composer/vendor/bin:$PATH"
17 |   - composer global require squizlabs/php_codesniffer
18 | 
19 | script:
20 |   - phpcs --standard=ruleset.xml --extensions=php -n -s .
21 | 


--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
  1 | # Contributing to Roots Projects
  2 | 
  3 | Please take a moment to review this document in order to make the contribution
  4 | process easy and effective for everyone involved.
  5 | 
  6 | Following these guidelines helps to communicate that you respect the time of
  7 | the developers managing and developing this open source project. In return,
  8 | they should reciprocate that respect in addressing your issue or assessing
  9 | patches and features.
 10 | 
 11 | 
 12 | ## Using the issue tracker
 13 | 
 14 | The issue tracker is the preferred channel for [bug reports](#bugs),
 15 | [features requests](#features) and [submitting pull
 16 | requests](#pull-requests), but please respect the following restrictions:
 17 | 
 18 | * Please **do not** use the issue tracker for personal support requests (use the
 19 |   [Roots Discourse](https://discourse.roots.io/) to ask the Roots Community for help, or if you want the Roots Team to dedicate some time to your issue, we [offer our services](https://roots.io/services/) as well).
 20 | 
 21 | * Please **do not** derail or troll issues. Keep the discussion on topic and
 22 |   respect the opinions of others.
 23 | 
 24 | 
 25 | <a name="bugs"></a>
 26 | ## Bug reports
 27 | 
 28 | A bug is a _demonstrable problem_ that is caused by the code in the repository.
 29 | Good bug reports are extremely helpful - thank you!
 30 | 
 31 | Guidelines for bug reports:
 32 | 
 33 | 1. **Use the GitHub issue search** &mdash; check if the issue has already been
 34 |    reported.
 35 | 
 36 | 2. **Check if the issue has been fixed** &mdash; try to reproduce it using the
 37 |    latest `master` or development branch in the repository.
 38 | 
 39 | 3. **Isolate the problem** &mdash; make sure that the code in the repository is
 40 | _definitely_ responsible for the issue.
 41 | 
 42 | A good bug report shouldn't leave others needing to chase you up for more
 43 | information. Please try to be as detailed as possible in your report.
 44 | 
 45 | 
 46 | <a name="features"></a>
 47 | ## Feature requests
 48 | 
 49 | Feature requests are welcome. But take a moment to find out whether your idea
 50 | fits with the scope and aims of the project. It's up to *you* to make a strong
 51 | case to convince the Roots developers of the merits of this feature. Please
 52 | provide as much detail and context as possible.
 53 | 
 54 | 
 55 | <a name="pull-requests"></a>
 56 | ## Pull requests
 57 | 
 58 | Good pull requests - patches, improvements, new features - are a fantastic
 59 | help. They should remain focused in scope and avoid containing unrelated
 60 | commits.
 61 | 
 62 | **Please ask first** before embarking on any significant pull request (e.g.
 63 | implementing features, refactoring code), otherwise you risk spending a lot of
 64 | time working on something that the developers might not want to merge into the
 65 | project.
 66 | 
 67 | Please adhere to the coding conventions used throughout the project (indentation,
 68 | comments, etc.).
 69 | 
 70 | Adhering to the following this process is the best way to get your work
 71 | merged:
 72 | 
 73 | 1. [Fork](http://help.github.com/fork-a-repo/) the repo, clone your fork,
 74 |    and configure the remotes:
 75 | 
 76 |    ```bash
 77 |    # Clone your fork of the repo into the current directory
 78 |    git clone https://github.com/<your-username>/<repo-name>
 79 |    # Navigate to the newly cloned directory
 80 |    cd <repo-name>
 81 |    # Assign the original repo to a remote called "upstream"
 82 |    git remote add upstream https://github.com/<upsteam-owner>/<repo-name>
 83 |    ```
 84 | 
 85 | 2. If you cloned a while ago, get the latest changes from upstream:
 86 | 
 87 |    ```bash
 88 |    git checkout <dev-branch>
 89 |    git pull upstream <dev-branch>
 90 |    ```
 91 | 
 92 | 3. Create a new topic branch (off the main project development branch) to
 93 |    contain your feature, change, or fix:
 94 | 
 95 |    ```bash
 96 |    git checkout -b <topic-branch-name>
 97 |    ```
 98 | 
 99 | 4. Commit your changes in logical chunks. Please adhere to these [git commit
100 |    message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
101 |    or your code is unlikely be merged into the main project. Use Git's
102 |    [interactive rebase](https://help.github.com/articles/interactive-rebase)
103 |    feature to tidy up your commits before making them public.
104 | 
105 | 5. Locally merge (or rebase) the upstream development branch into your topic branch:
106 | 
107 |    ```bash
108 |    git pull [--rebase] upstream <dev-branch>
109 |    ```
110 | 
111 | 6. Push your topic branch up to your fork:
112 | 
113 |    ```bash
114 |    git push origin <topic-branch-name>
115 |    ```
116 | 
117 | 10. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)
118 |     with a clear title and description.
119 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # Roots Coding and Contributing Guidelines
 2 | 
 3 | ## PHP
 4 | 
 5 | [PSR-2 coding style](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) with the following changes:
 6 | 
 7 | * 2 spaces indentation
 8 | * Opening and closing braces for functions and classes forced on the same line
 9 | * Forced newline after opening brace
10 | 
11 | Additional rules:
12 | 
13 | * Use `Roots\` namespace
14 | * Use short array syntax
15 | * Use short echo syntax
16 | 
17 | You can check if your contribution passes the styleguide by installing [PHP CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) and running the following in your project directory:
18 | 
19 | ```bash
20 | phpcs --standard=ruleset.xml --extensions=php --ignore=node_modules,bower_components,vendor -n -s .
21 | ```
22 | 
23 | ## JavaScript
24 | 
25 | Every JavaScript contribution is run against the [Google JavaScript Styleguide](https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml). You can check if your contribution passes the styleguide by installing [JSCS](http://jscs.info/) and running the following in your project directory:
26 | 
27 | ```bash
28 | npm run jscs
29 | ```
30 | 


--------------------------------------------------------------------------------
/ruleset.xml:
--------------------------------------------------------------------------------
 1 | <?xml version="1.0"?>
 2 | <ruleset name="Roots">
 3 |   <description>Roots Coding Standards</description>
 4 | 
 5 |   <!-- Use PSR-2 as a base -->
 6 |   <rule ref="PSR2">
 7 |     <!-- Allow opening and closing braces for functions and classes to be on the same line -->
 8 |     <exclude name="Squiz.Functions.MultiLineFunctionDeclaration.BraceOnSameLine"/>
 9 |     <exclude name="PSR2.Classes.ClassDeclaration.OpenBraceNewLine"/>
10 |     <exclude name="Squiz.WhiteSpace.ScopeClosingBrace"/>
11 | 
12 |     <!-- Disable newline after opening brace -->
13 |     <exclude name="Squiz.ControlStructures.ControlSignature.NewlineAfterOpenBrace"/>
14 | 
15 |     <!-- Disable PSR-2 indentation rules that are buggy with 2 spaces -->
16 |     <exclude name="PSR2.ControlStructures.SwitchDeclaration.BreakIndent"/>
17 |     <exclude name="PSR2.Methods.FunctionCallSignature.Indent"/>
18 |   </rule>
19 | 
20 |   <!-- Force 2 spaces indentation -->
21 |   <rule ref="Generic.WhiteSpace.ScopeIndent">
22 |     <properties>
23 |       <property name="indent" value="2"/>
24 |       <property name="tabIndent" value="false"/>
25 |     </properties>
26 |   </rule>
27 | 
28 |   <!-- Verify that operators have valid spacing surrounding them -->
29 |   <rule ref="Squiz.WhiteSpace.OperatorSpacing"></rule>
30 | </ruleset>
31 | 


--------------------------------------------------------------------------------