feat: add Lint API

[aminya]

Adds convenient API to lint string, file, and module

Issues

Fixes #17
Fixes #37
Fixes #14

Requires:

julia-vscode/SymbolServer.jl#190
julia-vscode/CSTParser.jl#209

TODO

• Add tests
• Add print lint function for REPL usage

[twolodzko]

@aviatesk @davidanthoff @pfitzseb is there a chance for this to be merged? The ability to run the linter from command line as a part of CI/CD would be great feature.

[pfitzseb]

Yes.

[davidanthoff]

I took a quick look and left some comments, but I think @ZacLN really needs to weigh in on most of the issues here.

[davidanthoff]

We can't take a dependency on that, it pulls in too many other packages.

[aminya]

I can move my PRs to this organization to a different package if you think you can't add a dependency, or the codes make you nervous.

[davidanthoff]

This comment was really narrowly talking about CodeTools.jl: I think that would pull at least five new packages in, and because we ship all packages manually for the VS Code extension that would add just too much extra work to keep all of that updated and maintained.

BUT, having said that: I think maybe having a new package that is user facing and exposes a simple API for LanguageServer, SymbolServer, StaticLint etc. might actually be the best design. Such a package could really primarily target REPL users and make things most convenient for them. It could also easily take on any additional dependencies that are not needed for the VS Code extension. Plus, you wouldn't have to deal with the bottleneck of our snail paced review times ;)

The general idea then would be that packages like StaticLint, SymbolServer, LanguageServer etc. are really targeting IDE integration authors, are low level and not user friendly, with a minimal API surface. And (your) new package would expose things for REPL/end users.

@ZacLN and @aminya does that make sense to you? We could actually host such a package here in the julia-vscode org, or @aminya you could also host it on your account, I'm indifferent on that.

[aminya]

That's OK. I can host a Lint.jl package on my account.

The old Lint.jl is not registered anymore.

[twolodzko]

Sounds like a good idea! @aminya could you ping me when you create it or if you need any help on it? I'd be lively interested in it.

@davidanthoff when there's a separate package for standalone linter, maybe this could be mentioned in Readme here as well so it would be easier for people looking for such functionality to find it?

[davidanthoff]

Yes, we could definitely change the README here to essentially say "This is a low-level package, go to Lint.jl for something that most users would want to use."

[davidanthoff]

Yeah, that is definitely key :) LS doesn't write any files, so it can be done, but I'm not familiar enough with the API to help out here.

[ZacLN]

From https://github.com/julia-vscode/StaticLint.jl/blob/master/test/runtests.jl:

using SymbolServer, StaticLint
function parse_and_pass(s)
    server = StaticLint.FileServer()
    ssi = SymbolServerInstance("/path/to/julia/depot/")
    _, server.symbolserver = SymbolServer.getstore(ssi, "/path/to/env")
    server.symbol_extends  = SymbolServer.collect_extended_methods(server.symbolserver)

    f = StaticLint.File("", s, CSTParser.parse(s, true), nothing, server)
    StaticLint.setroot(f, f)
    StaticLint.setfile(server, "", f)
    StaticLint.scopepass(f)
    StaticLint.check_all(f.cst, StaticLint.LintOptions(), server)
    return f.cst
end

[davidanthoff]

I'm not sure this lint_file API can work. StaticLint.jl really kind of operates on folders, I think, so not sure how this would fit in.

[ZacLN]

using SymbolServer, StaticLint

function parse_and_pass(path)
    server = StaticLint.FileServer()
    ssi = SymbolServerInstance("/path/to/julia/depot/")
    _, server.symbolserver = SymbolServer.getstore(ssi, "/path/to/env")
    server.symbol_extends  = SymbolServer.collect_extended_methods(server.symbolserver)

    f = StaticLint.loadfile(server, path)
    StaticLint.scopepass(f)
    StaticLint.check_all(f.cst, StaticLint.LintOptions(), server)
    return f.cst
end

[davidanthoff]

I am also not sure whether that API makes sense? I think we should probably limit the API to linting files and folders in some way.

The whole code around modulefiles also makes me nervous, and if we didn't have that API here we wouldn't need that code, right?

[ZacLN]

I'd just use the lint_file function on the Module entry file, so a thin wrapper function.

[davidanthoff]

So I'm going to close this here, under the assumption that we all are on board with a new package for the public API.

[takbal]

@aminya does 10ad459 achieve what you wanted? Are you planning to update Lint.jl with this, and add a working linter to juno/atom? It is the only feature missing there badly.

[aminya]

Yes, I will make the package over the weekend.

[takbal]

I have made a linter-julia fork that uses StaticLint:

https://github.com/takbal/linter-julia

PR:

AtomLinter/linter-julia#119

Possibly quite amateurish effort (I know nothing of js or Atom, and learning Julia just for a few months), but it seems to work so far. Please review @aminya