Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I saw your discussion in #756 (comment) and the following comments, and I think your preference seems to be to commit the lock file to the repo. Since I agree with that, I figure I would contribute that change.
To summarize some ideas about this:
By committing the lockfile you ensure that all contributors and the CI system share a common working environment, so no more "it works on my system" dependency issues for contributors running tests locally or getting the CI to pass.
People who prefer gitignoring the lockfile argue that by doing that you discover compatibility problems with your dependencies earlier. I think this is debatable because the set of end users is usually much bigger than the set of maintainers and contributors of your library, so those are more likely to discover those issues first anyways. In any case, I feel this concern is better solved through other means, for example, by running scheduled builds on your repo without the lockfile periodically and getting notifications about CI status changes, or by configuring dependabot to create PRs for new dependency releases in real time.
As an extra change, I moved development dependencies to the Gemfile. These dependencies are not used in runtime, they're only used for developing the library, and keeping them in the Gemfile is more flexible. For example, you can point them to git repositories or to local folders, which is something you cannot do inside the gemspec file.