AtomLinter/linter-eslint

* Ignore home config from disableWhenNoEslintConfig

* Move isConfigAtHomeRoot to its own file

It needs to be used in both worker and non-worker, so it’s easiest
to just put it in its own file for now until we re-structure.

* Extract copyFileToTempDir as test helper function

* Move temp dir creation to `copyFileToTempDir`

* Determine fix results based on exit code

Perhaps in the past ESLint threw an error if `--fix` did not fix all of
the errors in a file.  Or, maybe this logic was flawed from the start.
Either way, this change just looks at the exit code (`0` if there are 
no linting errors left, `1` if there are), and returns an appropriate
string.  Both cases are really success messages, there were no errors.

If there was an error for some reason, we need to print the `err.message`
string, because `addWarning` expects a string, not an error object.

* Do not attempt to fix on save when disabled

If `disableWhenNoEslintConfig` is disabling linting, we should also
not be trying to perform an autofix.

* Observe disableWhenNoEslintConfig config

* chore(package): update dependencies

https://greenkeeper.io/

* Update peerDependencies

Update to the following to satisfy the peerDependencies:

* `eslint@^3.12.0`
* `eslint-plugin-import@^2.2.0`

Move to babel-cli

Replace the current `ucompiler` setup with a standard `babel-cli` setup,
along with a configuration that transpiles _only_ what is necessary,
instead of the current method of transpiling everything that _might_ be
needed. This currently transpiles to support for Node.js v5 as that is
what Atom v1.10.0 ships with, which is our current minimum version.

…point

Gracefully handle invalid points

If the error doesn't look like one from rangeFromLineNumber, then just re-throw it.

Provide a note in the code as to why the points are all having 1
subtracted from them.

Correct the specs for the updated debug text.

Make the rule name in the generated issue show as code instead of raw
text.

The worker wasn't being passed into the call to `getDebugInfo()`
properly.

The generation of the trace messages doesn't need to be in the main
message processing.

Move processing of messages to a helper function so the code isn't as
complex in the main program.

Instead of throwing errors, trap the message and create a Linter message
telling the user that something went wrong. Include a link to report the
problem including all the debug information.

Move the generation of the debug string to a helper function as we will be
using to also generate debug information when creating an issue.

* chore(package): update eslint-config-airbnb-base to version 10.0.0

https://greenkeeper.io/

* Update peerDependencies

Update the minimum dev versions to:
* [email protected]
* [email protected]

* Cleanup ESLint config a little bit

Just removing some sections that are duplicated in `eslint-config-airbnb-base`.

* chore(package): update dependencies

https://greenkeeper.io/

* Update ESLint to v3.8.0

Minimum version to satisfy the peerDependency of
`[email protected]`.

Add issue template

Add ESLint to the devDependencies

As ESLint is not only a dependency of this project, but also used for
developing it, it should have been listed in here from the start. Brought
to the forefront by atom/ci#60 as we discovered
that linting wasn't actually running on the CI builds.

* Add support for endLine and endColumn

Add support for creating a full range from an ESLint message if it
specifies an `endLine` and `endColumn`. Also adds a `validatePoint` helper
function to check that these coordinates given from ESLint are valid since
we no longer have the checking built into `helpers.rangeFromLineNumber`.

This is a rebase and re-commit of 2310e86,
which was reverted in 6cd62e8.

* chore(package): update eslint-config-airbnb-base to version 8.0.0

* Update eslint-plugin-import to v1.16.0

Needed to satisfy the `peerDependencies` of
`[email protected]`.

* Fix lint issues

* Update ESLint disable style

Turns out you can send mutliple rules to `eslint-disable-next-line`.

https://greenkeeper.io/

Add setting for silencing rule ids

If the user hasn't configured any rules, don't add the argument.

Just like the other observed settings, for some reason it was out of scope
when we tried to access it.

Update the value expected to account for the proper spec initialization.