Ignore home config from disableWhenNoEslintConfig #778

Merged
merged 4 commits into from Jan 18, 2017

Projects

None yet

2 participants

@IanVS
Member
IanVS commented Jan 9, 2017 edited

Fixes #773

Description

This PR prevents an eslint config file located in a user's home directory (e.g. /users/person/.eslintrc) from enabling linting of projects within the home directory when the setting Disable when no ESLint config is found is enabled.

Note, because of the way we traverse up the directory structure looking for config files, projects outside of a user's home do not currently find a fallback config in a user's home, and thus those projects are already being disabled correctly.

Notes

This adds a dependency on user-home, which is used to detect the user's home directory and return it as a string. This result is compared to the directory containing the config file returned from the config file search, to determine if the file should be treated as a valid project config file or a fallback.

Also, I've added a few specs here around the disableWhenNoEslintConfig setting, but I wasn't able to create a good red-green test for the particular fix in this PR. That's because I could not find a way to mock the functionality of findCached in such a way to fake the finding of a config in the home directory. My plan was to put a file with linting errors in the OS temp dir, (not under the home dir), mock out findCached to make it seem there was a config file in the user home, and then show that with this PR, linting is still disabled. However, my go-to tool for such purposes, proxyquire does not seem to work correctly with electron's require implementation. If you know if any other way to mock dependencies in the way I'm attempting, I'd be keen to hear it.

How to test

Despite not having a good automated test for this change, it's fairly easy to check manually.

  • Put a .js file similar to the badInline.js file added in this pr, somewhere in your home directory, like ~/experiment/foo.js.
  • Assuming you don't already have an eslint config in your home, touch ~/.eslintrc
  • Verify that without the changes in this PR, the setting for disableWhenNoEslintConfig has no effect, and linting is performed on the file no matter the setting.
  • Then, with the changes in this PR, verify that linting is indeed disabled when (and only when) disableWhenNoEslintConfig is turned on.

Warning

The base branch of this PR is not master, but rather another branch with an open PR. I have a good feeling that other PR (#777) will be merged, and rather than rebase this branch afterwards, I've just based on that, and will move the base to master after #777 is merged.


This change is Reviewable

@IanVS IanVS requested a review from Arcanemagus Jan 9, 2017
@IanVS IanVS changed the base branch to master from issue511-fix-error-notification Jan 9, 2017
@IanVS IanVS Ignore home config from disableWhenNoEslintConfig
e3c5d6a
spec/linter-eslint-spec.js
+ atom.config.set('linter-eslint.disableWhenNoEslintConfig', true)
+
+ waitsForPromise(() =>
+ new Promise((resolve) => {
@Arcanemagus
Arcanemagus Jan 9, 2017 Member

Since this functionality is being used twice maybe it should be split into a function?

src/helpers.js
+ * @return {Boolean} [description]
+ */
+export function isConfigAtHomeRoot(configPath) {
+ console.log(userHome, dirname(configPath);
@Arcanemagus
Arcanemagus Jan 9, 2017 Member

Looks like this debug statement got left in 😛.

@IanVS
IanVS Jan 9, 2017 Member

whoops.

@@ -54,7 +54,8 @@ module.exports = {
// Do not try to fix if linting should be disabled
const fileDir = Path.dirname(filePath)
const configPath = getConfigPath(fileDir)
- if (configPath === null && disableWhenNoEslintConfig) return
+ const noProjectConfig = (configPath === null || isConfigAtHomeRoot(configPath))
+ if (noProjectConfig && disableWhenNoEslintConfig) return
@Arcanemagus
Arcanemagus Jan 9, 2017 Member

I'm personally not a fan of one line if statements, but I'll leave that up to you.

@IanVS
IanVS Jan 15, 2017 Member

That's how it was before, so I'm just going to leave it for now. :)

src/worker.js
@@ -6,6 +6,7 @@ import Path from 'path'
import { create } from 'process-communication'
import { FindCache, findCached } from 'atom-linter'
import * as Helpers from './worker-helpers'
+import { isConfigAtHomeRoot } from './helpers'
@Arcanemagus
Arcanemagus Jan 9, 2017 Member

helpers brings in a lot of things, and isn't intended to be used from the worker process (gotta love our convoluted design here...). Maybe this function should live in worker-helpers and helpers imports it from there? Either way is messy 😕.

@Arcanemagus Arcanemagus added the bug label Jan 10, 2017
IanVS added some commits Jan 15, 2017
@IanVS IanVS 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.
be754fd
@IanVS IanVS Extract copyFileToTempDir as test helper function
b82c03c
@IanVS
Member
IanVS commented Jan 15, 2017

@Arcanemagus I believe I've addressed your feedback.

@Arcanemagus

Whichever way you decide to go with this, this LGTM otherwise so feel free to merge afterwards!

spec/linter-eslint-spec.js
@@ -367,24 +380,14 @@ describe('The eslint provider for Linter', () => {
let editor
let didError
let gotLintingErrors
- let tempFixtureDir
- let tempFixturePath
+ const tempFixtureDir = fs.mkdtempSync(tmpdir() + path.sep)
@Arcanemagus
Arcanemagus Jan 18, 2017 Member

Since this is the exact same in both test cases, you could move it into copyFileToTempDir, if you want to leave it as a parameter though you might as well just call the function copyFileToDir 😛.

@IanVS
IanVS Jan 18, 2017 Member

I passed it in so that I could rimraf it after the test. Guess I could indeed rename it.

@IanVS
IanVS Jan 18, 2017 Member

@Arcanemagus I ended up moving it to the function after all. Seemed … cleaner, I guess.

@IanVS IanVS Move temp dir creation to `copyFileToTempDir`
65fbf9c
@Arcanemagus

LGTM

@IanVS IanVS merged commit fe0551b into master Jan 18, 2017

3 checks passed

ci/circleci Your tests passed on CircleCI!
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@IanVS IanVS deleted the issue773-ignore-home-config branch Jan 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment