Initial framework for plugins. The plan is to convert current processors / linters / formatters to plugins. Modelled after Kaocha.
There's several entry-points for plugins to hook into the processing pipeline, i.e. to extend the allowed cli-options, config or processing.
The new pipeline also enables cli-options and extensive configurability.
This PR should be considered experimental (and therefore is targeted to merge into development instead of master). Follow up PR's will also go into development until a satisfactory quality has been reached.
QA plan
Author checklist
[ ] I have QAed the functionality
[ ] The PR has a reasonably reviewable size and a meaningful commit history
[ ] I have run the branch formatter and observed no new/significative warnings
[ ] The build passes
[ ] I have self-reviewed the PR prior to assignment
Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
[ ] Correctness
[ ] Robustness (red paths, failure handling etc)
[ ] Test coverage
[ ] Spec coverage
[ ] Documentation
[ ] Security
[ ] Performance
[ ] Breaking API changes
[ ] Cross-compatibility (Clojure/ClojureScript)
Reviewer checklist
[ ] I have checked out this branch and reviewed it locally, running it
[ ] I have QAed the functionality
[ ] I have reviewed the PR
Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
Brief
Initial framework for plugins. The plan is to convert current processors / linters / formatters to plugins. Modelled after Kaocha.
There's several entry-points for plugins to hook into the processing pipeline, i.e. to extend the allowed cli-options, config or processing.
The new pipeline also enables cli-options and extensive configurability.
This PR should be considered experimental (and therefore is targeted to merge into
development
instead ofmaster
). Follow up PR's will also go intodevelopment
until a satisfactory quality has been reached.QA plan
Author checklist
Reviewer checklist