Integrate retext into repo

[gemfarmer]

More to come:

• https://github.com/wooorm/retext
• https://github.com/18F/retext-18f
• https://github.com/envato/zxcvbn-ruby
• https://github.com/envato/zxcvbn-js
• exec.js

[gemfarmer]

In order for PR #4 to work, we will need to arrive on a series of plugins that makes sense for 18F's purposes. @coreycaitlin started to put together a nice list of rules in the retext-18f repo.

The majority of plugins that we will need will be replacement rules

Some plugins to consider:

• retext-simplify: Check phrases for simpler alternatives
• retext-readibility: Detect possibly hard to read sentences.
• retext-equality: Adds warnings for possible insensitive, inconsiderate language to the processed virtual files.
• retext-overuse: Word overuse with Retext.
• retext-quotes: Check quotes and apostrophes, and warn if their style ("straight" or “smart”) or level of nesting is not the preferred style
• retext-repeated-words: Check for for repeated words
• retext-spell: Check spelling

Each of these plugins could be forked or cloned and renamed as retext-18f-[suffix] with custom rules. Many of these linters are too aggressive, so changing them to be more lenient is important. retext-simplify in particular could be leveraged to serve more generally as a replacement engine, retext-replace, perhaps.

Fortunately, because of the way that retext works, all the plugins should be able to have their results readily piped to one another via retext-unified and give a consistent response that includes a line number and response message, which is all that is truly needed to make Octokit.create_pull_request_comment work

[wooorm]

Thanks for using retext / unified! Do let me know if there’s questions I can answer.

As an aside, maybe instead of forking it’s possible to PR to the projects?

[gemfarmer]

@wooorm thanks for creating all of these awesome tools! I'm blown away by your work!

I was thinking that forking would be preferable to PRs because we would probably want to curate a more organization (@18F) specific version of some of the plugins. If there is a straightforward way to override plugins that would be even better! Is there a way to override plugins with custom rule sets?

[wooorm]

@gemfarmer Thanks, I appreciate it, that makes me very happy!

I was thinking that forking would be preferable to PRs because we would probably want to curate a more organization (@18F) specific version of some of the plugins. If there is a straightforward way to override plugins that would be even better! Is there a way to override plugins with custom rule sets?

If 18F-specific tools are created, forks are indeed best. However, most plugins support suppressing errors, take for example retext-spell, which allows an ignore array. There isn’t support for adding new words: that should probably be in new plugins, or as a PR to the plugin if it could benefit more people.

I’m not entirely sure about what you’d like to add, but I see the following as a good outcome:

• PRs to existing retext plugins which add new words benefiting everyone
• New plugin which checks 18F-specific rules
• New plugins checking new things (feel free to mention ideas in the Gitter for retext, I’d like to help)
• Possible a wrapper project which configures remark and retext plugins according to 18F rules

...though I’m not entirely sure if I’ve thought of everything!

[gemfarmer]

@wooorm I think a combination of some of the options you have laid out should work for us. I'm not sure that we will need a plugin that checks things in a functionally different way, but we haven't used this to check much content yet. I'll be sure to stop by Gitter if that becomes necessary.

Thanks again for being so responsive. I appreciate the guidance.