Probably should be done in Pipeline.transform(), as that's where we're currently sorting. Maybe pass the context to that method so we can read the config. Might also want to make the sort order configurable, too.

Support reading editorconfig data (if present) and make those values available to pass through to commands.

For example, many formatting tools support configuring indentation via a CLI flag. Stylist could allow for something like:

processors:
  - name: jsonfmt
    includes:
      - "**/*.{json}"
    fix:
      command: "jsonfmt --indent {{ .indent_size }}"
      input: variadic
      output: none

... where indent_size would be read from .editorconfig.

To implement:

1. We'd need to come up w/ some rules for how we resolve editorconfig values for a given batch of paths. Theoretically you can have values defined in .editorconfig per-file, though in practice most people likely have them defined per-filetype. If we're executing a command for a batch of files, which path do we use to determine the editor config values? Personally I think just using the first file will be fine, but we'd need to validate and document that.

2. After resolving editorconfig values, we'd need to run the command string through text/template. Might want to think about tools that don't expose flags and only support config files... maybe allow for specifying a config template that we render to /tmp and expose via a {{ .rendered_config_path }} var? Though if we want to do that, should create a separate issue.

Review linters from https://github.com/caramelomartins/awesome-linters
Don't need everything, just the more frequently used tools.

• actionlint
• black
• cspell
• eslint
• flake8
• gitleaks
• gofmt
• golangci-lint
• hadolint
• markdownlint
• prettier
• rubocop
• shellcheck
• shfmt
• stylelint
• terraform
• yamlfmt
• yamllint

If a processor returns an unknown severity level, stylist aborts and returns a semi-cryptic error message:

$ stylist check

Error: foo is not a valid ResultLevel

We should just fail gracefully and coerce any unexpected severity to error.

Add a dockerfile and devcontainer config to make it easier for others to contribute.

i.e. add the --gitignore flag.

possible options:

• location: path:line:column, source
• source: source, path:line:column
• severity: level, path:line:column

It's currently hardcoded to emacs, but would be nice to allow it to be set in the stylist config (maybe as syntax_highlight_style). The config is available as an attribute on the TtyPrinter struct, so it should be pretty straight forward to add.

Should probably validate the style names against the the list from chroma.

Currently we still calculate context lines even when the output.show_context config setting is set false. This can end up taking a huge amount of time in projects with a large amount of issues to report. We should only calculate context when the setting is true.

Something like:

[shellcheck] bin/command.sh:6:6 Double quote to prevent globbing and word splitting. (SC2086) <https://www.shellcheck.net/wiki/SC2086>

On by default, but users can disable if it's too busy.

Inspired by tomasbjerre/violations-lib. Would probably involve the following types:

• Result (and subtypes)
• ResultMapping
• OutputParser (and implementations)

Not 100% sure if it's a good idea or not, but tracking here so I don't forget.

If a gitignore file is present, we should auto-exclude any listed patterns.

• There should be a config option to opt-out of this behavior.
  • We already need to add the context to PathIndexer, could pull the Config out of the context.
• See: PathIndexer.exclude for where to hook place the logic.
• See: https://github.com/sabhiram/go-gitignore

Should probably have a config option and flag, too.