Repository navigation
Conversation
Related to issues adobe#3269, adobe#4210. Based on the discussion and suggestions in adobe#3310. If a project has a .jslint.json in its root, it gets loaded and passed to each JSLint run within the project. The configuration file gets reloaded each time it is saved or refreshed.
|
This is not supposed to be a "complete" feature. I just created all the machinery needed to support project-wide JSLint configuration. Those who use it, could create the file manually and configure JSLint as they like. This same mechanism could be later used to create UI-based JSLint configuration: a dialog which would write the JSLint config file and the file itself could be hidden from the project tree. I wanted the machinery to be separate from the UI though. On global JSLint config: I actually think it might not be a good idea, if it's located in home. Normally, there's no JSLint configuration which would suit any project (due to global, different runtimes, e.g. node vs. browser). Brackets could have a default Brackets-wide configuration (which options it would contain, by the way?) and the per-project configuration would be applied over it. Do you think there's a need for a feature like this? |
|
There's some work going on right now to explore preferences and make a plan in general. My own preference would be to see that work come to fruition first, because it would likely include a mechanism that would support project-level JSLint settings. That said, if there was a single config file that could be used by Brackets and by jslint/grunt on the command line, that would be an argument in favor of having a JSLint-specific file. |
|
Thanks! I saw @peterflynn had an item in Trello as well as some discussions in the related issues. I also saw some notes in the code that would suggest that Brackets would switch to JSHint (why?). Is there a discussion on the mail list I should look at? As far as I know jslint is simply a function call that would accept a text and a config object and, per se, does not have any configuration file. People created some wrappers to run it on the command line, is it what you refer to? At any rate, I see how this pull request needs to be aligned with a bigger discussion. |
|
@dangoor, I understood what you were saying wrt jshint/grunt. Do you have a policy against using symlinks in the git repo? If not, it would be very easy to link the two config files: link /src/.jslint.json to /.jshintrc. They do have the same format, naturally. |
|
@busykai I'm not completely sure, but some of what you're saying above seems to relate to the Brackets project and its use of JSLint/JSHint and the original feature for which you opened the pull request is more generally for Brackets users. In my comment on this pull request, I was specifically talking about the feature of allowing users to configure JSLint/JSHint for their projects. This will be covered by any preference system work we do. But, as you mention, some people do have command line (or Grunt) integration for JSHint/Lint and we might consider having Brackets read a file there so that the configuration can easily be shared between Brackets and those tools. But, I think we'd want to settle on our preferences design first (which is something I'm hoping we'll do very soon!) For Brackets itself, I believe the reason we're looking at JSHint is that it offers a bit more flexibility. I don't remember seeing this on the googlegroup. You're certainly welcome to open a general discussion about JSLint vs. JSHint there if you're interested. Currently, we use JSLint in Brackets and JSHint on Travis-CI for the Brackets project. We'd prefer to just use JSHint but haven't gotten around to that. There's a Trello card for use of JSHint as well. |
|
Hi @busykai. We've been talking about preferences some more and I'm sure there will be some additional docs posted beyond some initial thoughts that I posted. We really don't want a proliferation of individual config files for various features and do plan to support project-level prefs. I'd like to close this pull request for now with the thought that we will have a project-level preferences mechanism in the fairly short term. If it looks like it's going to take a while to get project-level prefs, then we can look to merge this in. I'd hate to see people create .jslint.json files and then have to deprecate that feature shortly in favor of a new storage format. Thanks for your work on this patch and thoughts about our approach here! |
ADAPTED FROM adobe#4380 If present, on project load or reload, a .jslint.json file in the project root will be loaded as the options passed to JSLint instead of the default brackets.json::jslint object. Also setting JSLint as the JSON linter since it can handle that format as well. TODO: Use DocumentManager to refresh the options if the .jslint.json file changes.
Just found out this feature has been proven unnecessary by the .brackets.json project-level config file. However, I can't get the "jslint.options" property of .brackets.json to work when I try it, so this custom solution involving a .jslint.json file still seems to be the only way I can get custom options. Since it works, and I can't seem to do it "the right way", here's the cleaned up code based on the original adobe#4380 even if it may be deprecated.
Related to issues #3269, #4210.
Based on the discussion and suggestions in #3310.
If a project has a .jslint.json in its root, it gets loaded and passed to each
JSLint run within the project. The configuration file gets reloaded each time
it is saved or refreshed.