### What needs to get done A design spec for the linter service that addresses the following: - The service’s API - Protocol for the linters themselves - Do we want different types of linters? (e.g. do we want to distinguish linters that warn about issues with the inputs and linters that warn about issues with the resulting objects?) Example use case for pre-linters and post-linters - A Charmcraft pre linter may warn about out-of-date charmlibs before beginning pack, whilst a post linter may error because the resulting charm contains neither hooks nor a dispatch file. #### Acceptance criteria * A new abstract linter class * A new linter service * Usage of the linter service in testcraft * Documentation for how to add a new linter #### Implementation hints Begin with the [AnalysisService from Charmcraft](https://github.com/canonical/charmcraft/blob/main/charmcraft/application/commands/analyse.py) and the [LinterIssue from Snapcraft](https://github.com/canonical/snapcraft/blob/a5682c276cea484efd21b86379f9a7bc9f30450d/snapcraft/linters/base.py#L51-L81). Use something roughly like the linter implementation in both (find commonalities), but make the `run` method a generator that yields zero or more issues. ### Why it needs to get done Snapcraft and Charmcraft lint snaps and charms respectively at the end of the lifecycle. These linters don’t share common code and don’t have a similar UX. Additionally, there isn’t a way to add linters to other *craft apps without significant code duplication.