This will help keeping `unused`'s install-plan from bitrotting over time and therefore avoid our Haddock doc builder failing to rebuild docs, as well as users running into compile errors, and last but not least reduce the overhead for us Hackage Trustees having to step in and fixup .cabal files :-)
(see also documentation at https://docs.haskellstack.org/en/stable/yaml_configuration/#pvp-bounds)
See also https://matrix.hackage.haskell.org/package/unused which shows that most install-plans for `unused` have already bitrotten
Why?
====
rg is oftentimes faster for searching across a codebase than ag;
however, it's newer and potentially more unfamiliar, so ag still remains
the default.
This is an introduction to supporting rg, but without updating the
Homebrew recipe yet. Given a trial run, I can imagine switching to it as
a default eventually.
These columns were not well-explained and, with limited space for
headers, often led to confusion.
This removes the columns. The data is still displayed in the more
verbose output (currently visible when seeing corresponding commit SHAs,
via the `--commits #` flag).
Closes#60
This resolves an issue where data/config.yml is unavailable with an
error similar to:
/private/tmp/stack66398/unused-0.6.1.0/src/Unused/ResultsClassifier/Config.hs:22:23:
Exception when trying to run compile-time code:
data/config.yml: openBinaryFile: does not exist (No such file or directory)
Code: FE.embedFile "data/config.yml"
In the splice: $(FE.embedFile "data/config.yml")
Outline ctags usage for developers familiar and unfamiliar with the tool
This introduces a new section to "Troubleshooting" outlining ctags
usage, as well as discussing the merits of a repeatable workflow for git
users.
When installing 0.6.0.0 via Homebrew, a compilation error is shown:
src/Unused/Projection.hs:27:34: error:
• Expecting two more arguments to ‘ParseError’
Expected a type, but ‘ParseError’ has kind ‘* -> * -> *’
• In the first argument of ‘Either’, namely ‘ParseError’
In the type signature:
parseTransform :: Text -> Either ParseError ParsedTransform
cabal: Leaving directory '.'
cabal: Error: some packages failed to install:
unused-0.6.0.0 failed during the building phase. The exception was:
ExitFailure 1
Given we're rendering the output as a string with `show`, this moves
`show` to where we parse and pass the `String` around instead.
Basic aliases (e.g. `admin?`/`be_admin`) can be represented easily with simple
wildcards, but more complex transformations require a different mechanism.
Instead of using `%s` to represent strings that can be replaced 1:1, this
introduces a syntax inspired by https://github.com/tpope/vim-projectionist, as
such:
- name: Rails
aliases:
- from: "*Validator"
to: "{snakecase}"
This would find `AbsoluteUriValidator` and also match `absolute_uri`, which
would be found if the validation was in use.
This currently supports the `camelcase` and `snakecase` transformations,
as well as no transformation.
Closes#18
Previously, aliases were calculated twice:
1. when building out the list of terms to search for
2. when merging results into TermResults for grouping (and likelihood calcs)
This problem was masked by the fact that wildcard matching on both ends
was the same, with '%s'. However, the goal is to move away from simple
'%s' matching and do a system where transformations can be applied to
the text, which would address #18.
This moves us one step closer to fixing that issue.
Why?
====
After the introduction of:
safeReadFile :: FilePath -> IO (Either E.IOException String)
There were places who needed to repack data into the appropriate type.
This is an extra step and, while in these situations not necessarily
*slow*, should be removed.
This introduces a Readable typeclass which dictates implementation of
`readFile'` based on the resulting requested type. This means `safeReadFile`
can be used in various situations without having to `pack`.
This replaces readIfFileExists, which has a race-condition and may raise
an exception, with safeReadFile, which safely reads a file and includes
the IOException if something goes wrong.
Unused is not a tool where you can remove code without verifying
behavior still works, since it's most valuable in dynamic languages like
Ruby, Elixir, JavaScript, etc.
Common scenarios right now seem to be:
* Issues with the cache, and specifically find
* Seeing no results when results are expected
This discusses a few different reasons for those issues, and ideas of
how a developer might address them.
