Problem: In
```
import qualified Foo.Bar as Bar
import Foo.Bar (Bar)
```
names of the imported modules are on different
vertical lines, which disables autosorting,
and makes it harder to read.
Solution: Use `ImportQualifiedPost`
Problem: Stack cannot build projects with mixins, and they only
used to splice universum instead of base.
Solution: Use `NoImplicitPreduce` and import `Universum`
everywhere explicitly.
Problem:
We have `exec` directory with `Main.hs` which (from semantic) supposed
to only run Xrefcheck.
Also, it's a common practice to keep `Main.hs` as simple as it possible.
But now it have some logic.
Solution:
Move commands related functionality to lib (separate module) and keep
`Main.hs` very simple, only as runner.
Problem:
Almost all the time we can't validate localhost links, so we just skip them.
But to run ftp links tests (#47) we need to refer to localhost.
Solution:
Add config option whether to ignore localhost links and provide bats
tests for this new feature.
Co-authored-by: Alexander Bantyev <alexander.bantyev@serokell.io>
Problem: now when we include repository type into the config, it seems
to make sense to generate config differently depending on the repository
type. Especially taking into account that currently in some fields we
mix GitHub and GitLab -specific contents.
Solution:
Leave placeholders in the default config and later fill them from the
code depending on the required repository type.
Add a mandatory repository type parameter to `dump-config` CLI command.
Along with a test checking for config validity, add a golden test on the
produced config so that we could assess how sane it looks like.
Problem: it turned out that GitHub and GitLab render anchors for headers
differently.
Solution: make it possible to specify flavor in config, adjust
headers conversion respectively. Added some fixes for GitHub as well.
Flavor field is mandatory, so this change is breaking, but I
think it's a worthy thing since otherwise other subtle bugs are
possible, it should be good if users specify the flavor as soon
as possible.
Problem: we have two major use cases:
1. Using xrefcheck in CI, in this case it is annoying for devops to
always pass mostly always reasonable `--no-progress` option.
2. Using it locally, here we want progress bar to be enabled by default
so that user could run `xrefcheck` without any options most of the time.
Solution:
Detect whether are we running in CI and use the respective default for
whether progress bar should be displayed.
Detecting whether we are within CI is possible using `CI` env variable,
at least Github actions, Gitlab CI and Buildkite pass this env.
`--no-progress` option still can be passed if user wants to suppress
progress bar in local run. The opposite `--progress` seems to also make
sense, because in case if high timeouts are set, user probably wants to
track progress somehow to make sure that CI didn't hang. So we add the
latter, and these two options can be used to override the default
behaviour defined by `CI` env var.
Problem: when launching our verifier with `-v`, visually separating
repository data section from found errors section is difficult.
Solution: make section headers more noticable.
Problem: it is often a case that in CI we copy xrefcheck repository into
the verified project, and we want to exclude folder with xrefcheck from
scan. Considering this in config is not too convenient, better add a CLI
option.
Solution: add this CLI option.
As in config, I call it `ignored`, because simpler `excluded` is too
general and it's not obvious what exactly it refers to - the set of
verified files or the set of supposedly non-existing files (in the
latter case references _to_ such files should also be prohibited).
Problem: we use many unusual unicode characters, on some locales this
may cause failures on attempt to print to stdout.
Solution: it is generally a good practice to set encoding of all
handlers to UTF-8, and this commit brings `with-utf8` package which does
that.
Problem: module names are prefixed with `Crv` which does not suit the
new project naming.
Solution: following the new `xrefcheck` name, rename modules so that
they start from `Xrefcheck`.
Problem: nowadays we want all files to store licensing information in
machine-readable format and to use reuse tool to check that. But the
repo is not REUSE compliant.
Solution: add `LICENSES` folder and licensing information for each
file.
Problem: after recent fix the user has to specify configuration file
even if it is present in the working directory of crossref-verify run.
That's not convenient.
Solutiion: if custom config path is not specified, first try to find
it under common filenames. When configuration file is not found anyway
we now print a warning before falling back to default config.
Problem: currently `crossref-verify` executable does not work without
configuration, and user was supposed to use one from the repository if
he does not have its own. This is very inconvenient.
Solution: make executable remember some config and use it by default.
