Contributing to Susy
Susy exists because of your contributions. Bug reports and feature requests are welcome, but code is even better!
In all cases, we ask you to follow the Sass community guidelines.
Susy is roughly divided into two layers, the core grid-math layer is called Su, and is made up of “pure” functions that expect normalized values.
The “Susy” layer provides extra syntax-sugar to the API – with parsing, normalization, and a smaller set of “common” functions that call on the core math as necessary.
Set up your environment with the appropriate development dependencies:
As you work…
- Add or update any appropriate unit tests
testdirectory, and make sure all tests are passing with
- Add your changes to the changelog
- Update or add inline documentation
using SassDoc as appropriate,
and compile the docs with
npm run sassdoc
The primary API functions
all have unprefixed alias functions:
Any changes to arguments or defaults
should be made in both locations.
Linting, testing, and documentation should be done before every commit:
npm run commit
They can also be triggered individually:
# lint npm run lint # test with mocha/true, and compile ag-test CSS npm test # compile full test output for reference npm run compile # compile docs npm run sassdoc
npm run test-libsass for js-only tests,
rake test for ruby-only environments.
Once you’ve fixed any final errors or typos, commit your changes, and submit a pull request!
We use the
main branch for production-ready code,
and side-branches for everything in-progress
When submitting a patch via pull request:
- Write a clear, descriptive commit message
- Keep it simple: one bug fix or feature per pull request
- Update the version number in both
- Updated the changelog & release date
npm run commit
- Release on Github
- Publish release to NPM