Implement a feature to enable user to run custom checks

[ankita240796]

Implement a feature via which a user can specify path to a custom checks folder and run them.

[ankita240796]

@Nytelife26 these are the design ideas I have come up with. Want to verify before proceeding:

Option 1

• User can provide a path to a file that has custom checks. These checks are self-sufficient and do not depend on proselint tools. The file should contain a check method which will be run on input files.

Option 2

• User provides a path to a custom folder that contains checks implemented in the same format as proselint/checks. These checks can use tools defined in the proselint folder.
• While running checks, we copy over this sub-folder to proselint directory and run all checks within this folder. After the run is complete, we delete the copied over folder.

I feel option 2 is the better way to go here since it allows user to utilize the existing functionality. The only extra work here will be to validate the checks provided by user as input and ensure that they are in the same format as proselint checks.

[ankita240796]

I can share a detailed design doc once we confirm the approach to take.

[Nytelife26]

We had quite a lengthy discussion about this already.

In the end, @suchow and I came up with the idea to:

• Host a directory of official extension checks that, while not universally applicable, may be useful to some and are maintained to a high standard under our ethos so people can download them if they so wish
• Add a CLI argument to pass a local checks folder. Copying the local folder over would not be necessary, since proselint exports its tools as library functions, so local checks can still use them regardless of where they are located.

So, I think we should do everything to encourage putting people's work in the main repository and ensure the ones in there are well-vetted, good, high-quality extensions, but people are still allowed to point to their own local checks if they really want to or during development.

[ankita240796]

To confirm, the scope of this issue would be to fix the second part? Further, this might help as well: updating the readme to encourage people to submit their checks in the main repo: including instructions on creating a new check and explaining the significance of the test before submitting it to the main repo.

[ankita240796]

Add a CLI argument to pass a local checks folder. Copying the local folder over would not be necessary, since proselint exports its tools as library functions, so local checks can still use them regardless of where they are located.

What about the config in this case? Should we expect the user to provide an updated config where all custom checks are also listed or should it be assumed that all custom checks are to be run even if not mentioned in config?

I am in favour of an updated config - just to be consistent with how the existing checks are run.

[Nytelife26]

To confirm, the scope of this issue would be to fix the second part?

What do you mean by that?

updating the readme to encourage people to submit their checks in the main repo: including instructions on creating a new check and explaining the significance of the test before submitting it to the main repo.

Perfect suggestion, that was part of what we were planning :) I can draft up the README changes, but we first need more consensus on the plan here.

What about the config in this case? Should we expect the user to provide an updated config [...] or should it be assumed that all custom checks are to be run even if not mentioned in config?

Configuration should never make erroneous assumptions - if they want to enable these additional checks every time, they must be specified in config. Else, we can only rely on CLI args for individual sessions.