Contributing

March 25, 2026 ยท View on GitHub

If you discover issues, have ideas for improvements or new features, please report them to the issue tracker of the repository or submit a pull request. Please, try to follow these guidelines when you do so.

Issue reporting

  • Check that the issue has not already been reported.
  • Check that the issue has not already been fixed in the latest code (a.k.a. master).
  • Be clear, concise and precise in your description of the problem.
  • Open an issue with a descriptive title and a summary in grammatically correct, complete sentences.
  • Include the versions of Chewy, Elasticsearch, Ruby, Rails, etc.
  • Include any relevant code to the issue summary.

Development setup

Prerequisites

  • Ruby 3.2+
  • Docker (for Elasticsearch)

Starting Elasticsearch

The test suite expects Elasticsearch on localhost:9250. The easiest way to start it is with Docker Compose:

docker compose up elasticsearch_test -d

If you prefer a native Elasticsearch installation, use the provided Rake tasks instead:

bundle exec rake elasticsearch:start # start Elasticsearch on port 9250
bundle exec rake elasticsearch:stop  # stop Elasticsearch

To point the test suite at a different host or port, set the ES_HOST and ES_PORT environment variables.

Running tests

bundle exec rspec                          # run the full suite
bundle exec rspec spec/path/to_spec.rb     # run a single file

Running RuboCop

bundle exec rubocop

Testing against different Rails versions

Chewy maintains gemfiles for each supported Rails version. Set BUNDLE_GEMFILE to test against a specific one:

BUNDLE_GEMFILE=gemfiles/rails.8.0.activerecord.gemfile bundle exec rspec

Available gemfiles:

  • gemfiles/rails.7.2.activerecord.gemfile
  • gemfiles/rails.8.0.activerecord.gemfile
  • gemfiles/rails.8.1.activerecord.gemfile

Pull requests

If you're new to open source, How to Contribute to Open Source is a great place to start.

  1. Fork the repository (http://github.com/toptal/chewy/fork)
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Implement your changes, cover them with specs, and make sure existing specs still pass
  4. Commit your changes (git commit -am 'Add some feature')
  5. Push to the branch (git push origin my-new-feature)
  6. Create a new pull request

When preparing your pull request:

  • Use a topic/feature branch to easily amend a pull request later, if necessary.
  • Write good commit messages.
  • Use the same coding conventions as the rest of the project.
  • Commit and push until you are happy with your contribution.
  • If your change has a corresponding open GitHub issue, prefix the commit message with [Fix #github-issue-number].
  • Make sure to add tests for it. This is important so it isn't broken in a future version unintentionally.
  • Add an entry to the Changelog.
  • Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or it is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.
  • Make sure the test suite is passing and the code you wrote doesn't produce RuboCop offenses.
  • Squash related commits together.
  • Open a pull request that relates to only one subject with a clear title and description in grammatically correct, complete sentences.

Changelog entry format

Here are a few examples:

* [#753](https://github.com/toptal/chewy/pull/753): Add support for direct_import parameter to skip objects reloading. ([@TikiTDO][], [@dalthon][])
* [#739](https://github.com/toptal/chewy/pull/739): Remove explicit `main` branch dependencies on `rspec-*` gems after `rspec-mocks` 3.10.2 is released. ([@rabotyaga][])
  • Mark it up in Markdown syntax.
  • The entry line should start with * (an asterisk and a space).
  • If the change has a related GitHub issue (e.g. a bug fix for a reported issue), put a link to the issue as [#123](https://github.com/toptal/chewy/issues/123): .
  • Describe the change briefly. The sentence should end with punctuation.
  • If this is a breaking change, mark it with **(Breaking)**.
  • At the end of the entry, add an implicit link to your GitHub user page as ([@username][]).
  • If this is your first contribution to the project, add a link definition for the implicit link to the bottom of the changelog as [@username]: https://github.com/username.