Search for .jshintrc file by scanning up directories from the current file instead of checking the root of the project only

[EvHaus]

JSHint docs current state:

"In case of .jshintrc, JSHint will look for this file in the current working directory and, if not found, will move one level up the directory tree all the way up to the filesystem root. (Note that if the input comes from stdin, JSHint doesn't attempt to find a configuration file)"

• http://www.jshint.com/docs/

However, brackets-jshint currently only scans the project root directory for this file.

Can we update the extension to behave the way JSHint was designed?

[luizfilipe]

I just thinking about this issue, brackets can´t handle the current file path for inspection?

the problem seems be in main.js when has the usage for ProjectManager.getProjectRoot().fullPath this must be changed to a current file path without file name, im not sure if code that fix the issue is the code below:

function getJshintrcFile () {
  var dirPath = document.file.fullPath.split('/');
  var result;
  while ( dirPath != ProjectManager.getProjectRoot().fullPath && !result) {
    dirPath.pop();
    result = FileSystem.getFileForPath(dirPath.join('/') + '.jshintrc');
  }

  return result;
}

I´ll spent some time on this, cause now i´m just learning how to build the environment to test and debug the this plugin code...

[busykai]

@globexdesigns the behavior simulating node's version of jshint behavior will be implemented once support for asynchronous providers will be in place. it will be soon, hopefully. currently, as you mentioned, only the file at the project root is loaded (it's documented in README.md at the very top), because the only opportunity to load anything is the start-up and it's done in a hacky way.

however, i don't think it should go beyond the project tree. it's not a good thing for an extension to scan the entire filesystem. the most important use case, IMO, for the project tree scan are submodules which may use different jshint settings. it is important to distinguish node's jshint executable and brackets extension based on JSHint api. i believe brackets should limit its scope of fs acces to the project root. at the end, jshintrc setup is (ideally) once per project and it contains project-specific settings, such as "global" section.

[jhofker]

Any update on this since sprint 37 was released?

[cfjedimaster]

The ability to do async linting wasn't adding in 37 afaik.

[Sebl29]

+1 I Make use of shared .jshintrc files in many projects. The recursive search is JSHint standard, so the plugin should not do less. As an alternative I would suggest to be able to set a default .jshintrc file, as I was used in Sublime-Linter plugin. Having another config for each project is a definitive no go, with an eye on the new config options of JSHint for 2.4.* and now 2.5.0.

[fedfigca]

+1 It's been awhile so I thought I just ask again if this is possible now in 1.2 somehow, it is really important for those of us doing fullstack javascript projects, as the server side .jshintrc is very different from the client side.

[cfjedimaster]

I'm open to someone doing a PR for this.