Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AndroidLint support #1089

Open
rougsig opened this issue Jan 12, 2022 · 5 comments
Open

AndroidLint support #1089

rougsig opened this issue Jan 12, 2022 · 5 comments

Comments

@rougsig
Copy link

rougsig commented Jan 12, 2022

I have a large project, I would like not to check it all. I only want to check the changed files. AndroidLint haven't that feature. I need to write wrapper to implement it. It can be cool, if i can use AndroidLint from spotless with git ratchet feature.

Does spotless support AndroidLint?

@nedtwigg
Copy link
Member

It doesn't, but we'd be happy to take a PR which adds it. In this and #143 you're proposing adding support for linting tools rather than formatters.

A key thing to understand about Spotless' current model is that a FormatterStep is just a String -> String (more details here).

Perhaps we could create a new infrastructure for linters like so:

public class Lint {
  int lineStart, lineEnd;
  String lintId;
  String comment;
  @Nullable String replacement;
}

public interface LintStep {
  public List<Lint> lintsFor(String formattedUnix, File file);
}

We could then add a List<LintStep> lintSteps to Formatter

private List<FormatterStep> steps;
private FormatExceptionPolicy exceptionPolicy;

A computed result would become String cleanTxt, List<Lint> lintsOnCleanTxt.

Whenever adding a big feature like that, I think it's key to have at least two actual clients and ideally three. We now have:

  • detekt
  • androidlint
  • ktlint (sorta)

So I think that's enough to test this out. If anyone is interested in writing something along these lines I'd be happy to help them.

@rougsig
Copy link
Author

rougsig commented Jan 12, 2022

Sounds great. So i think. detekt should be implemented with that model String -> Optional<ErrorMsgAndLocation>. It can be cool, if you can help me with LintStep infrastructure.

@nedtwigg
Copy link
Member

I'll push up a draft PR for the infrastructure of this.

@rougsig
Copy link
Author

rougsig commented Jan 13, 2022

In fact ktlint is linter too, not only formatter. May be more correct abstraction for spotless is str -> Pair<str, issue[]>, where left is autofixed issues, right is list of issues which used sould fixed manually.

Or we shoud create two kind of aggregation? Formatter and Linter.
where, Formatter is pure function str -> str, Linter is pure function str -> Pair<str, issue[]>.

@nedtwigg
Copy link
Member

A PR against #1097 would be very welcome, for any of the linters discussed :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants