rmm5t
commented
6 years ago @Chubchenko Ah. Thank you. You read it. 😄
We already have Travis, Gemnasium, Code Climate, and Coveralls configured on this project.
overcommit:
I'm not a fan of abusing, or automagically running a bunch of commands as a side effect when a developer isn't expecting it. i.e. If I run git commit, I want it to do only what I've configured it to do. If I've configured my own git hooks, great, but I don't like the pattern that's forming where each repository wants to inject their own set of hooks for the purpose of code analysis or babysitting what the developer is trying to do. There shouldn't be an expectation that something like overcommit is necessary. Besides, Travis can solve the same underlying problems that overcommit tries to solve, albeit in a more asynchronous way.
fasterer:
No. More time would go wasted in maintaining this configuration than would yield any benefit in performance enhancement on this kind of project.
rubocop:
rubocop has some benefits in teams with mixed experience level just to keep a consistent codebase, but I find tools like this (and other opinionated static code analyzers) get in the way more often than they actually help improve code quality.
At the end of the day, it's the test suite that matters. Does it test the correct behaviors? Does it have decent and real code coverage? Does it clearly state the requirements and specifications so someone new can understand the intended behavior? The other development tools are all a far distant 2nd to a clean and automated test suite. Add a good Travis build-matrix, and you get even better insight into a shared library like this one.
Furthermore, these tools really only benefit projects that have a lot of churn and a lot of rapid developer activity causing that churn. [That does not apply to stripe_event]().
With all that said, if you're interested in running any of the above tools (without tying them directly to this project) and submitting small and discrete individual pull-requests based upon some of their recommendations, I'd be happy to review some of those, but please make sure that each pull-request has an single purpose (e.g. Hash#each_key is preferred over Hash#keys.each). A pull-request with a bunch of intermingled changes sprinkled all over the place is less likely to get reviewed or merged.
What do you think about adding the next tools: