This linter uses the check functionality built into terraform. ALE
already has a fixer using `terraform fmt` but this doesn't provide error
messages. ALE already has a linter using `tflint` but this requires an
extra application to be installed.
For example this linter will give a warning that ! is an illegal
character in the line below:
variable "example" !{}
This linter runs the buffer through the command below and parses the
output:
terraform fmt -no-color -check=true -
This commit includes a basic implementation, documentation and tests.
The only option is to control which executable is run.
Tested with:
$ terraform -version
Terraform v0.11.13
We were setting the -data parameter to the project root but this caused
the language server to fail initialization and synch of gradle
dependencies. As consequence ALE failed to work fully on gradle
projects.
This fix sets the workspace to the parent folder of the project root.
Normally this corresponds to the correct Eclipse workspace path.
When this is not the case, this fix also allows users to explicitly set
the absolute path to the workspace via configuration variable.
* Search eclipselsp jar and config files within system package path
* Allow setting an alternate eclipselsp configuration directory
* Add test for ale_java_eclipselsp_config_path
- Set default value to $HOME/eclipse.jdt.ls
- Make JAR search regexp more specific.
- Allow to set the VSCode extensions folder as ale_java_eclipselsp_path.
* move php-langserver "test for .git dir" test-project to its own directory
* search for composer.json file in php-langserver first then .git dir
* add test for php-langserver composer.json
When using `gotype` without the `-e` option, it will only output the
first 10 errors. When working on a larger package that ofter means taht
those 10 errors are in other files then the one that you are currently
working on which then seems to indicate that there are no errors.
By adding the `-e` flag, all errors will be returned and shown properly
in the file that you are working on.
* Add credo --strict option
If a user sets 'let g:ale_elixir_credo_strict=1' it will run credo with
--strict instead of suggest. The default (0) is to run as suggest.
* Added credo docs
Bandit automatically [uses any .bandit file] within the directories on
which it is invoked. Since ALE invokes bandit on stdin, it does not
load a .bandit file automatically. Add support for automatically
finding a .bandit file and passing it to bandit via the --ini option
along with a variable to disable this behavior if desired.
Note: This is useful for the skips and tests configuration options, but
not exclude which would require invoking bandit using a file name, which
may or may not be a good trade-off.
[uses any .bandit file]: https://github.com/PyCQA/bandit/blob/1.5.1/bandit/cli/main.py#L70-L73
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Pylint only [checks for pylintrc] (and .pylintrc) files in the packages
aboves its current directory before falling back to user and global
pylintrc. For projects with a src dir, running pylint from the
directory containing the file will not use the project pylintrc.
Adopt the convention used by many other Python linters of running from
the project root, which solves this issue. Add pylintrc and .pylintrc
to FindProjectRoot. Update docs.
[checks for pylintrc]: https://github.com/PyCQA/pylint/blob/pylint-2.2.2/pylint/config.py#L106
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
Although using %t to lint changes was desirable, many pylama checks use
surrounding paths and file contents (e.g. C0103 module name, E0402
relative import beyond top, etc.) The more such errors I find during
testing, the less %t seems like a good idea. Switch to %s.
Also set `lint_file` to 1 and mark Pylama as a file linter in the docs.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
As discussed in w0rp/ale#1051, there are cases where it would be useful
to be able to specify the dialect explicitly. This commit allows users
to do so using the ale_sh_shellcheck_dialect variable.
Fixes: w0rp/ale#1051
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The vulture linter already supports ale_python_vulture_options, but it
is not documented or tested. Since vulture only supports configuration
via options, it is an important use case. Add docs and test.
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
The executable for the Alex linter is currently hard-coded as 'alex',
which is an issue given the fact that it conflicts with the Haskell
lexer generator, whose executable is also called 'alex', has been around
a dozen years before the linter, and is packaged in the official
repositories of the major Linux distributions.
This commit adds options to use a local executable for the alex linter
(which is a node package), and an option to set a custom executable.
As side changes:
* The pattern in the alex handler is made more readable by turnig it
into a very-magic regex.
* Alex handles plain text, markdown, and HTML. Specific flags for HTML
and markdown are provided when instantiating the linters for the
respective filetypes, while before those formats were treated as plain
text.
* Add initial ameba (crystal linter) support
Note that this depends on saved file as `ameba` does not have STDIN
support
* Fix formatting of crystal linter documentation
* Add tests for ameba executable customization
* Add support for https://github.com/saibing/bingo
* Add docs for ale-go-bingo
* Use go.mod when found
* Add test for bingo FindProjectRoot
* Simplify ale_linters#go#bingo#GetCommand
With earlier elm versions, a separate package file is maintained for
tests, which when properly configured enabled the compiler to find what
it needed to compile the tests. Under elm 0.19, test dependencies are
managed in the top-level package file, so `elm make` will fail on the
tests. `elm-test make` is required in this case.
See https://github.com/elm-explorations/test/issues/64
- added a cd into the direcotry containing the file in the buffer
in order to properly check for a config file
- added command_callback tests for graphql
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?
The linter can correctly parse pydocstyle output with any of the following
command-line options enabled: --explain, --source, --debug, and/or
--verbose
The command used to invoke the LSP process was being escaped wrong.
Also added a new option to set a different java executable and fixed the
documentation.
Previously, elixir-ls would treat each sub-project within an umbrella as
standalone, which isn't desirable from a language server perspective.
Added ale#handlers#elixir#FindMixUmbrellaRoot, which locates the current
project's root and then continues searching upwards for a potential
umbrella project root. This literally looks just two levels up to keep
things simple while keeping in line with Elixir project conventions.
Use this new function to determine elixir-ls's LSP project root.
