Filters linter

[ameshkov]

I'd like us to have a filters linter (just like there's eslint for JS or all kinds of linters for golang). Once we have it, we can have a Github action that runs it on every commit.

@zloyden please come up with a spec, use https://eslint.org/ as a reference

1. What rules this linter should have?
2. What would be the command-line interface?

[zloyden]

The filters linter should validate rules, according to the syntax https://kb.adguard.com/en/general/how-to-create-your-own-ad-filters and abort code execution using various options. This can be similar as eslint, but adapted for our goals. What I mean by validate our rules:

1. According to the link above, checking the right syntax of the rules.
2. Checking the minimum length of the rule, not including special syntax symbols.
3. The linter must recognize the rules by category.

For those goals, the linter must be executed after git command git commit -m "name of the commit" or if the command is executed via GUI interface.

There should be our own commands that can be written in the terminal and executed manually.

• yarn rules - global check for the all rules of the current repository.
• yarn rules path_directory- it should be the same like yarn filter, but limited to the specific path - path_directory.
• yarn rules commit - checking the rules that have been added only in the current commit.
• yarn scriptlets - the same command as yarn rules, but it checks only specific type of the rules - scriptlets. There should be similar commands for each type of the rules.

What I mean by abort code execution using various options:

• Abort code. If the linter found errors in the code, it would create a list of errors (name of the error that should expain a mistake, place of the error - this link should be clickable if possible) and display it on the console, after that abort execution code git commit -m "name of the commit". If the linter didn't find the error/s, it would create a notification no errors, display this in the console and let git commit -m "name of the commit" be executed. That's a basic behaviour.

• Confirmation notification. This filters linter mode should be optional and used only if there are rules from a certain category. The linter should also create an error, display it on the console and after that, create a confirmation field in which the user must accept the changes or not. If there is a positive confirmation, user should write yes (alias y) and the linter should let the code execute. If not, user should write no (alias n) -> the linter should abort the code with displaying errors.

Another thing we need to have is a configuration file that we can change manually according to our needs. It must contain an array of validation parameters with values. "parameter" - parameter of the validation. List of values: off - the linter should be disabled. error - the linter should use Abort code. warn - the linter should use Confirmation notification. There should be a global parameter as "linter": off, if we need to disable filters linter. For example:

{
        "minLength": off,
        "scriptlets": off,
        "basic": error,
        "JS": warn,
        "replace": [
             "error",
             "warn"
  ]
}

The linter have to be compatible with Windows and MacOS platforms.