chanzuckerberg / miniwdl

Workflow Description Language developer tools & local runner
MIT License
173 stars 54 forks source link

Support optional linting for style guides #194

Open dinvlad opened 5 years ago

dinvlad commented 5 years ago

Hi folks,

Would it be possible to support optional linting against a "style guide"?

We could describe conventions for workflow/task/variable/.. names (e.g. as regexes), newlines/tabs/spaces within tasks/calls (as numbers), etc., and then pass that info to WDL.Lint, to have it check the source against those conventions and return suggested edits.

Thanks!

mlin commented 5 years ago

Checking names against regexes would be easy to add as a module within the existing linter infrastructure.

Right now the lexer discards whitespace, so the information for examining the layout isn't in the AST. This would definitely be nice to have, as well as recording code comments in the AST for linter suppression. (There is a MixedIndentation linter but it applies only to task commands, where we do have the whitespace)

At a meta level, I've come to really appreciate black for removing all arbitrary layout decisions in miniwdl's own Python code, and would like this for our WDLs too :) In addition to the above requirements though, miniwdl has nothing at all yet for WDL code/syntax generation.

I'm on a hard sprint for the immediate future fleshing out the internal workflow runner, but definitely I'd like to have all of this on the intermediate-term roadmap!

mlin commented 5 years ago

PS: we could sort of get at whitespace by looking at the distance between neighboring SourcePosition.{line,end_line,column,end_column} nodes, but this would be pretty hacky and also wouldn't distinguish spaces and tabs.

dinvlad commented 5 years ago

Agreed - perhaps it’s worth prototyping name regex checks as a good start. I think the suggested edits could be returned as messages with pos that spans the start and the end of an affected symbol. Perhaps we could use a specific format of the message to then be able to parse out the actual edit in LSP (and/or display it to the user in a standardized form), like [styleguide]: Task_name or similar.