Ignoring nested .jshint files about atom-jshint

[Joezo]

If i'm honest the implementation for finding the correct config file to use and how it uses it isn't quite right at the moment. Will get around to sorting this out though if nobody puts in a pull request :)

[atuttle]

Is it supposed to be .jshint or .jshintrc?

[erikdonohoo]

It is supposed to be .jshintrc files—
Sent from Mailbox

On Fri, May 9, 2014 at 7:45 AM, Adam Tuttle [email protected]
wrote:

Is it supposed to be .jshint or .jshintrc?

Reply to this email directly or view it on GitHub:
#30 (comment)

[atuttle]

@Joezo I see how config is searched for and loaded here

I wouldn't mind taking a stab at trying to improve it. Did you have anything specific in mind?

[erikdonohoo]

Ideally when a file is saved (or being edited) a search would start from the directory of the file open and continue up the tree until a .jshintrc file is found. This way if you have a different configuration for jshint in a test directory than you do for your project overall, those rules would be respected instead

[erikdonohoo]

But this loading and searching for configuration would need to occur each time the active file is changed or saved, not just when atom opens.

[Joezo]

I'm not sure the search for config would need to happen each time a file is saved, just when is it opened would suffice? We could keep a hash of what config file is relevant to each open file so that we don't even need to search every time we switch file. Obviously we would need to if a new file was opened. The only concern there is if a file is moved, or a new config file is placed in the folder after the we've already searched. I'm really open to suggestions though and as long as the code works and doesn't slow things down i'd be happy to accept PRs. Please do have a go!

[erikdonohoo]

Keeping the hash is a good call. If the hash has a full file path to a config to use then when a file is moved it would be invalidated and a new config would need to be found for it. And when a new .jshintrc is created somewhere in he project the cache could just be invalidated so that searches could take this into account.

[Joezo]

Sounds like a good plan to me 👍

[atuttle]

Just found this: https://github.com/tkellen/node-liftoff -- maybe it would be useful here?

[Joezo]

This is now resolved and will be usable in the next release