Contributing to Assemble
With some differences, this guide is based on the excellent Twitter Bootstrap's CONTRIBUTING.md
Looking to contribute something to Assemble? Here's how you can help.
We love questions, and we love knowing how you're using Assemble. Before you create a new issue on one of Assemble's repos, please consider asking on
StackOverflow.com. This is entirely up to you, but your question and any answers to it are more likely to help other users in the future than a closed issue on GitHub. Also remember to add the
assembletag to your question!
Please read the following guidelines before opening any issue.
- Search for existing issues. To avoid duplicate issues, it would help us out if you could please check first to see if someone else has reported the same issue. Moreover, the issue may have already been resolved with a fix
- Create an isolated and reproducible test case. Be sure the problem exists in Assemble's code with a
reduced test case that should be included in each bug report. Check to see if there is an existing issue over on the
- Include clear examples. Make use of jsFiddle or jsBin to share your isolated test cases.
- Share as much information as possible. Include version of Assemble, customized or vanilla build, etc. where appropriate. Also include steps to reproduce the bug.
Notes on the repo
Assemble's documentation is maintained at
assemble-docs and is built with Assemble. Any edits to the docs should be first done in the templates and then recompiled into the HTML.
- Any changes to the docs must be made to the Handlebars templates, not just the compiled HTML pages
- CSS changes must be done in
.less files first, never just the compiled files
- Try not to pollute your pull request with unintended changes--keep them simple and small
Please use correct language definitions next to the markdown backticks in code examples, even if the language is not supported by GitHub Flavored Markdown. This is important because we want to ensure that when a develper
searches for "handlebars", Assemble's relevant documentation will show up in the results. B
For example, the Handlebars is not supported as a "language", so you might be tempted to use
```html so that you can take advantage of code highlighting, but you should still do
```handlebars. The same is true
for the LESS language, please use
```less instead of
Coding standards: HTML
- Always use proper indentation
- Two spaces for indentation, never tabs
- Double quotes only, never single quotes
- Use tags and elements appropriate for an HTML5 doctype (e.g., self-closing tags, and don't add the unnecessary closing forward slash.)
Coding standards: CSS
- Adhere to the
Recess CSS property order
- Multiple-line approach (one property and value per line)
- Always a space after a property's colon (.e.g,
display: block; and not
- End all lines with a semi-colon
- For multiple, comma-separated selectors, place each selector on it's own line
- Attribute selectors, like
input[type="text"] should always wrap the attribute's value in double quotes, for consistency and safety (see this
blog post on unquoted attribute values that can lead to XSS attacks).
Coding standards: JS
- Please use semicolons
- Single quotes, except where double quotes are necessary
- 2 spaces (no tabs)
- strict mode
- Consistent formatting with the rest of the code
See the template for this page →