Jshint seems to have pretty good defaults, so a short config line like this might be enough for most node js files we have. /* jshint node:true, unused:true, indent:4 */ One very simple option it is to start adding this config line in every file, and then just run jshint without any extra config.
This also allows for slight variations between the files, e.g. sub:true is useful for files that deal with XML parsing to prevent jshint from complaining about doc['key'] where doc.key looks like better JS but is not really appropriate because it's an XML doc. Jasmine files will need pretty long whitelist of globals since (afaik) there is no Jasmine preset for jshint. The other config method that allows for different configs for parts of the project are several .jshintrc files, e.g. one in src/ and another one in spec/. On Thu, Apr 24, 2014 at 6:15 PM, Shazron <[email protected]> wrote: > jshint doesn't focus on formatting: jscs does, and is like uncrustify that > I mentioned. > > As for a jshint-like thing for non-JS platforms, for iOS - there is OCLint > http://oclint.org/ > > > On Thu, Apr 24, 2014 at 2:22 PM, Jesse <[email protected]> wrote: > > > I agree that jshint is awesome and powerful, I use it all the time, and > so > > should you. > > That seems like a great end to this discussion ... > > Otherwise, how do we address the 50% of our code that is not JS? > > > > @purplecabbage > > risingj.com > > > > > > On Thu, Apr 24, 2014 at 2:15 PM, Martin Gonzalez Glez < > > [email protected]> wrote: > > > > > jshint is really cool. Agree, +1 for jshint. > > > > > > A couple of questions about this, which are gonna be the validation > > rules? > > > I mean, we have to be in the same page about which are gonna be those > > > rules. > > > Besides, how the users are going to use it? First they need to have the > > > node module installed, and then, use a set of validation rules that we > > are > > > going to provide? > > > > > > How it's gonna be? use a .jshintrc file with all the rules, general > rules > > > provided by the community, or each cordova component would contain a > > > jshintConfig/package.json with specific validation rules. CLI+rules, > > > platforms + rules, plugins + rules > > > It's gonna be optional(recommended)or as requirement to deliver code, > the > > > usage of jshint before commit files? the contributors would need send > any > > > evidence, that proves that their code has passed the validation? > > > Any thoughts? > > > > > > Jshint, it's awesome and a really good solution, I really like it. > > > > > > -Martin. > > > > > > > > > 2014-04-24 10:55 GMT-05:00 Marcel Kinard <[email protected]>: > > > > > > > Big +1 for jshint. > > > > > > > > On Apr 23, 2014, at 5:53 PM, Brian LeRoux <[email protected]> wrote: > > > > > > > > > This may get rotten eggs thrown at me but I think it would be good > to > > > add > > > > > jshint to the project. > > > > > > > > > >
