dxw / whippet

Whippet is a framework for building WordPress sites that eases deployment, plugin management and build steps.
MIT License
14 stars 3 forks source link

Refactor WhippetHelpers #227

Open snim2 opened 1 year ago

snim2 commented 1 year ago

This issue derives from a conversation on #224.

WhippetHelpers is a trait that provides a number of capabilities that are used in several Whippet commands. We should refactor it because:

  1. Classes with names like ThingHelpers are a code smell in themselves. The name is not self-documenting and suggest that the class does not adhere to the SRP.
  2. Traits do not make clear the relationships between classes, doubly so when a trait contains state, really they should be mixins.
  3. We have been inconsistent in how we decide where the top-level directory of a Whippetised repository is. In whippet_init() we search for the directory in a way that prevents us from mocking the filesystem. In some commands we don't. We could just check that the CWD contains whippet.json and is the root a repository and fail otherwise, but we don't always.
  4. We still have some code that searches for plugins.json which is related to a previous dependency management scheme that we no longer used. This should be removed.
  5. There are hidden dependencies between methods in the trait. For example, load_application_config() assumes that project_dir has been set by whippet_init() or something else. This makes it harder for client classes to use the trait.

There are various options for refactoring this trait, but I would suggest something like: