Closed schneems closed 3 years ago
I intended it as a runtime/regular dependency. Are you hitting problems or bugs with it?
-- Richard Schneeman https://www.schneems.com he/him
@schneems no, it's my general view on minimising dependencies, so I was keen to hear your thoughts on the matter. It looks for me like a good workflow gem, that teams should opt-in if they want, like say pry
, but usually gems don't bring pry
as a runtime dependency even if it's useful.
Either way, I'm fine with it, just thought I'll bring it up if it was accidential.
I generally agree. I want to get this as a dependency for some other gems that are more appropriate, such as rubocop. But I need a stepping stone first as it's an extremely high volume gem. Derailed seemed like a much smaller footprint and, of course, I have commit already so it's much easier. Also, many people use derailed only in the development gemfile group, which will limit exposure as well.
I intentionally bumped the major version to indicate a possibly large change. I also planned the release of this for a time when I knew I had sufficient attention to be able to triage issues or remove the integration if a serious one comes up. I've honestly not heard anything with a thousand plus downloads and counting https://rubygems.org/gems/derailed_benchmarks/versions/2.0.0 . I'm hoping that's a positive sign (in that it's not caused any issues). It's very difficult to get feedback as a maintainer sometimes.
My long term goal would be to remove this functionality from derailed and other gems and have it directly in Ruby, though that will be much more difficult than even getting it adopted by rubocop.
Hey @schneems, it looks like a great gem! I was thinking though if it should be development_dependency of the gem?