target: rework modtime comparison logic #323

[jasonmf]

Within the target package:

• Separate discovery of newest target timestamp from source inspection
• Allow source inspection functions to bail out as soon as they hit a timestamp newer than the target

~/p/mage/target$ go test -count=1 .
ok      github.com/magefile/mage/target 0.073s

[DavidGamba]

I love this separate approach, the only other thing that I would add to this, which is the reason I don't use mage target is because in the logs I want to see a report of the file I found that was modified. Sometimes there are complex dependency trees and knowing what triggered what is helpful.

[jasonmf]

I started out trying to make it compatible with the upcoming io/fs interfaces to make it easy to write tests that didn't have to touch the filesystem. This would also allow user implementations that return atime, ctime, or other arbitrary times. Ultimately I saw there were already perfectly good unit tests so I got lazy. I might revisit this when io/fs lands and then users can inject whatever funky filesystem behavior they want.

[natefinch]

Mostly LGTM with a couple tiny tweaks

[jasonmf]

Requested changes pushed

[natefinch]

So, coming back to this, now that I better grok why there's an expanded API surface, I'm a little more ok with it. Letting people punch in their own modtime does make the code more flexible.