isort is great, but I've come to prefer reorder-python-imports. The tool
has a focus on smaller diffs than isort. reorder-python-imports is also
a little smarter than isort which is nice.
Similar to other linters/fixers, by default change to the directory of
the file being fixed before invoking `black`, which allows the tool to
read project-specific configuration (pyproject.toml)
Fixes#2218
* Mimic Prettier's default parser by setting it to `babylon`
* Add tests to check default Prettier `parser`
* Set Prettier default parser based on version
* Update the comment to explain the reason for an explicit default
See: https://github.com/testdouble/standard
StandardRB is to RuboCop what StandardJS is to ESLint. This commit
naively copies the RuboCop linter and fixer to point at the standardrb
executable. Any other adjustments are very minor (the only I can think
of is that standardrb takes a `--fix` option instead of
`--auto-correct`).
This raises a confusing point to me as both developer and a user: since
ale enables all linters by default, won't this run both RuboCop and
StandardRB (the results of which will almost always be in conflict with
one another)? How does ale already solve for this for the similar case
of StandardJS and ESLint?
Problem: ocamlformat is configured to format files in-place and thus go
via creating a temporary file for that. Because temporary file resides
in a different directory ocamlformat can't find `.ocamlformat`
configuration files in an original location of source files.
Solution: ocamlformat since version 0.8 can read sources on stdin and
spur result on stdout. We reconfigure ocamlformat to use a simpler
interface.
* Add better support for Haskell stack compiler tools
This commit adds support for `stack` as the executable of a tool. This
follows a pattern that has been implemented for `bundler`'s tool chain.
* Move hlint command to linter file
* Add vader test for stack exec handling
* Update ghc-mod to support stack execution
`ghc-mod` was previously broken into 2 linters.
1. ghc_mod
2. stack_ghc_mod
This additional linter is not necessary with proper support for
executable variables and `stack exec` handling.
* Support stack exec in hfmt
* Support stack in hdevtools
* Don't add newlines when not a control statement for Python
* Add test for accidental newline fix
* Add docstring detection to avoid adding unnecessarily newlines
* Add tests for docstring detection
