Extract Guard::UI into a separate gem

[e2]

TL;DR - UI functionality should be in a separate gem to solve many problems

Basically to decouple the functionality from Guard, because it's a maintenance nightmare:

• reliance on global state
• dependency on other Guard:: modules (even though it's just for outputting in color)
• mixing up logging with screen output
• hard to refactor without breaking compatibility
• hard to test because of global state / singleton
• color handling is not transparent
• too many responsibilities in one class (logging, option handling, coloring, line reset, deprecations, screen clearing, scope name, backtrace filtering, requiring win32console) while none are actually Guard-specific
• options exposed as a hash makes little sense (logger options during init) and just makes the interface confusing

[rymai]

👍

[e2]

Promoted to "bug", because guard-plugins depend on UI/notify functionality (but do not need anything else from guard) - and this causes problems for users.

[ioquatix]

What can we do to simplify this?

[ioquatix]

I thought about this.

There is quite a bit of code in guard for doing stuff like color, logging, etc, which is now better handled by standard logger, rainbow, with a custom formatter.

Why not deprecated all of the global state, deprecate guard-compat, and then inject that state into the classes directly.

e.g.

class Plugin
    def initialize(logger)
       @logger = logger
    end

    attr :logger
end

class MyPlugin < Plugin
end

We could add some compatibility hooks to make this as easy as possible. I think if you expose the global state, it's going to be an endless battle.

[ioquatix]

We'd have to probably to a major version bump to implement this, but we could do it with minimal impact.

Perhaps we can tie it into the inevitable updates to listen.

[ioquatix]

I've been working on https://github.com/socketry/guard-falcon and I've tried to figure out what a guard-plugin should look like.

Making the gem name a class e.g. class Guard::Falcon < Plugin is a small mistake that makes it hard to define Guard::Falcon::Version, so I've made (as is recommended by RubyGems) module Guard::Falcon with a method ::new which forwards/constructs Guard::Falcon::Controller. I guess it could be called Plugin too.

Ideally we'd just use local methods on the class, e.g. #logger as I've added, but this should be defined by Plugin.

We can do a fair amount of monkey patching to fix old plugins, including adding to the plugin base def Compat; self; end and alias UI logger which would allow a lot of existing code to continue working without any changes.

Thoughts?

[ioquatix]

Another option is that we completely break away from the inheritance method of doing things, and use a module instead - e.g. Guard::Falcon is a model which defines start, restart, and so on, and can expect some standard things to be defined, e.g. attr :options. We then write something like Guard::Plugin.new.extend(Guard::Falcon). I think this was mentioned elsewhere. I'd be okay with a breaking change like this in a major version release, if the value of doing so was significant.

Ideally, we probably make a new gem, guard-plugin, which implements the very core plugin class, provides some testing harness, etc. Similar to guard-compat, but in a way that doesn't work based on the old assumptions, and allows users to incrementally update the plugins.

[rymai]

I think we should move away from the inheritance model, but I would argue that Guard should provide a module that plugin classes would include:

module Guard
  module API
    # A module with the content of the current Guard::Plugin
    # Guard::Plugin#initialize would show a deprecation warning.
  end
end

module Guard
  module RSpec
    class Plugin
      include ::Guard::API
    end
  end
end

The benefit is that Guard::RSpec would become a module.

See #873, guard/guard-compat#6, and guard/guard-rspec#397.