Make it possible for a linter to register itself via atom.services.

[bolinfest]

The goal is for clients of linter to avoid the following declaration
that they have to do today:

var Linter = require(atom.packages.getLoadedPackage('linter').path + '/lib/linter');

I don't know whether this change is a good idea, but I tested it and
it does [mostly] work. This amends package.json to declare the following
services:

  "consumedServices": {
    "linter.addLinterClass": {
      "versions": {
        "0.1.0": "addLinterClass"
      }
    }
  },
  "providedServices": {
    "linter.provideLinterClass": {
      "versions": {
        "0.1.0": "provideLinterClass"
      }
    }
  },

A client would then add the following to its package.json:

  "consumedServices": {
    "linter.provideLinterClass": {
      "versions": {
        "0.1.0": "createSubclassForLinterClass"
      }
    }
  },

which it would implement as:

'use 6to5';

module.exports = {
  createSubclassForLinterClass(linterClass) {
    class MyLinter extends linterClass {

    }
    MyLinter.prototype.cmd = 'some command';
    MyLinter.prototype.linterName = 'my-linter';
    MyLinter.prototype.regex = /some regex/;
    MyLinter.syntax = 'source.js';

    atom.services.provide(
        'linter.addLinterClass',
        '0.1.0',
        MyLinter);
  },
};

The major drawback to this scheme (other than it being weird) is
that MyLinter will be registered after the initial set of
LinterViews have been created. Therefore, messages from MyLinter
will not be shown in existing editors, but they will be shown in
any new editors that are created.

This could be worked out if this scheme were determined to be worth pursuing.

An alternative approach to avoiding the atom.packages.getLoadedPackage('linter').path
call would be to offer Linter via npm so it can be require()'d directly.

This would also make it easier for clients of linter to unit test their code.

[bolinfest]

Has there been any discussion around moving linter.coffee to npm? I concede that maintaining both an apm package and an npm package is more work, but it's probably simpler for developers (modulo version skew).

One other approach would be to favor composition over inheritance. That is, if the client provided some object that was composed by Linter rather than one that extended it, it would decouple things further.