@epriestley, with regards to "namespacing" linter configuration I'm ultimately happy with whatever, but is it really necessary to namespace the options? AFAIK, namespacing is effectively achieved by the type of the linter configuration.

i.e. In the following example, deprecated.functions is implied to be phutil-xhpast.deprecated.functions.

{
  "linters": {
    "phutil-xhpast": {
      "type": "phutil-xhpast",
      "include": "(\\.php$)",
      "deprecated.functions": {
        ...
      }
    } 
  }

I don't think it's strictly necessary, but, e.g., the C# linter (or something) adds an option called discovery. If we come up with some meaningful option called discovery later on that we'd like to put at the ExternalLinter or Linter levels, we'd be conflicting with the key in the subclass.

We'll probably never have a generic deprecated.functions, but something like discovery doesn't seem completely out of the question.

This also means that copy/paste issues will be caught immediately if someone transfers similar things between linters.

And .arclint should be written only very rarely, so it's not like we're extracting a high price in keystrokes...

I feel that a better approach would be to nest any linter-specific configuration under a common key rather than rely on the linter to choose a non-conflicting key.

For example,

{
  "linters": {
    "phutil-xhpast": {
      "type": "phutil-xhpast",
      "include": "(\\.php$)",
      "config": {
        "deprecated.functions": {
          ...
        }
      }
    } 
  }

However, if you'd prefer phutil-xhpast.deprecated.functions then I'll settle for that.