linter reporting #109
Closed
linter reporting #109
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
vemv
reviewed
Feb 3, 2020
28 tasks
|
Rebased against master |
|
FYI I think it was a good mistake from my side to rebase this against master :) I'll review the Kondo+Reporters stuff at the same time, improving things directly where possible. We've kept this in the oven for far too long now - this weekend I think I can just be done w/ it |
vemv
reviewed
Feb 8, 2020
vemv
force-pushed
the
reporting
branch
2 times, most recently
from
f8557d8 to
65cd85c
Compare
|
The Kondo cache part looks correct - enabled now. QAd in JVM clj so far - lgtm: I can trigger a Kondo warning (e.g. This proves that a cached version of a given ns doesn't interfere with a fresh analysis of that same ns. |
A simple measure might be to rearrange columns:
|
Part of #91
(At least for the time being) `formatting-stack.linters.kondo` already has logic for separating clj from cljs options.
Part of #69
It's the first publicly-available release.
Already offered by Eastwood.
Said linter can very easily trigger a lot of false positives.
* Prefer truncation to padding * Use a hierarchical format * Prefer coloring to icons * Make coloring optional * (far simpler than detecting tty capabilities, from what I could research) * Within a given file report, group the reports by `:source` Accordingly, `reporters.printer` has been discarded.
This trades some eagerness, in exchange for a faster first run of kondo.
By making the emitted :column/:line info more variable, users can get an idea of how greatly was a given limit surpassed.
A callback passed to `process-in-parallel!` shouldn't return a lazy computation, since that would make the parallel machinery useless (a lazy computation is expressed in parallel, but it's only realised later, in a non-parallel context).
The idea is to place linters with a best usefuleness/speed ratio first.
This allows restoring `ensure-coll` its old semantics, preventing complexities.
Now it can handle files containing invalid syntax. There was a previous attempt of this, but too coarse-grained.
It would be anomalous that Eastwood hit a syntactically broken anyway - it could indicate room for improvement in strategies/etc.
28 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brief
In a quest to make f-s more adoptable / easier to understand:
Adds an intermediate format for linters to allow more control over reporting. If this is acceptable I'll progress with formatters and process!
related #64, #48
TODO
:typeis added we can handle exceptions and suggestions/warnings as well.:typeseems better due to different contents of the mapsQA plan
nothing yet
Author checklist
Reviewer checklist