Support Ruby < 2

[Josua Schmid]

Migrating old projects involves migrating to new versions of Ruby. But I cannot do this without touching project code. Undercover would be the perfect tool here, but I cannot use it, because of imagen's dependency. But since imagen is also your gem, I guess this is not a problem, right 🤓 ?

[Jan Grodowski]

Thanks for submitting this issue. I didn't think of that use case, sounds good!

Bad news is that parser already depends on Ruby 2.0.0+, so running undercover on < 2 seems nontrivial. However, good news is that parser itself can parse older ruby syntax versions while running on 2.0.0+. So it will either just work (unlikely), or we need to add a flag like --target-ruby-version to the CLI to select the version for parser to use.

I have captured the above in grodowski/imagen_rb#7

@schmijos do you think that's a good solution for you?

[Josua Schmid]

Sure, that sounds lovely!

[Jan Grodowski]

@schmijos I started looking into this here grodowski/imagen_rb#26

[Jan Grodowski]

@schmijos check out 0.2.0 🙃

[Josua Schmid]

Hm… I'm not sure how to use it. I cannot configure undercover in the spec_helper.rb directly but I've to call it manually, correct?

The problem is if I switch the ruby version, my repository gets changed because I use rbenv:

[Jan Grodowski]

I didn't think about it while implementing -r! Two ideas right now, but I might update this answer as I think more about it... Please be aware this is an early project 😊

1. quick workaround: you can run the undercover command from a different directory (with -p path/to/project option) to avoid changing the rbenv dotfile, or maybe run without changing the local shim. That's on my machine:

$ rbenv local
2.4.4
$ ~/.rbenv/versions/2.5.1/bin/ruby ~/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/undercover-0.2.0/bin/undercover
✅ No reportable changes
Undercover finished in 3.2789s

2. I think we could start a new issue and make the Coverage data is older than your latest changes message only affect .rb files from the diff - it makes little sense right now me thinks...

Adding a dedicated spec_helper config interface to run the analysis just after specs is another cool idea! Would be great for non-concurrent CI environments.