Migrating from Timecop to ActiveSupport time travel about clockwork-test

[kevin-j-m]

Good question/suggestion which I don't have an entirely satisfying answer for how to proceed. I'm a fan of ActiveSupport's travel_to features and use them in my new rails projects.

ActiveSupport is currently a dev dependency of the project (for ease of test writing), but is not part of the dependencies for the gem proper.

However, it's unclear to me what the future of clockwork's relationship with ActiveSupport is. It was removed, but that was then reverted. I'm not sure if there's still appetite to remove ActiveSupport.

That said, we could have AS as a dependency and if users want to use this gem, then they'll have pulled in AS by using this, whether or not clockwork includes it. I wonder if keeping Timecop helps in having a smaller library targeted towards a specific problem, rather than pulling in all of AS for this one feature of it.

What do you think?

[brain-geek]

Yeah, it's a good question. If/when clockwork removes AS dependency, it would be a bad idea to have it in this project, as it's too big dependency to have.

One other thing to consider: it feels like Rubocop is more dead than alive. Even deprecation-fix PRs from 6+ month ago are not merged . While it works now, it may break. For example, Ruby 2.4 time objects have timezone-related changes, so it may function incorrectly.

[kevin-j-m]

I'm certainly wary of dependencies and the affects they may have in your library, and should we start to see issues with Timecop, then I'm much more motivated to consider alternatives (of which, the only one I'm aware of that still has any traction or use would be AS).

However, at this time, I'm concerned that this may be trying to solve a problem that we don't have right now, and our time may be better spent in other ways. Do you think that's a fair assessment?

[brain-geek]

This decision is up to you - and at the moment this may be a bit too early - Timecop is still good.

Thanks for discussing this anyway! 😄