On Wed, Jan 21, 2015 at 5:47 PM, Murat Sutunc <[email protected]> wrote:
> I can take a look at applying current rules in all subfolders soon if time > constraints were the reason. > Will be greatly appreciated. Though I would advise to start from something other than then specs folder for your own sanity :) > I suspected that real time jshinting was the reason for having jshint > rules in individual files but by doing so we lose track of un-hinted files > and hint standardization. It would be nice to have a standard set of rules > for the folder/project and have exception rules in individual files. If > spec-cordova, spec-plugman and src should all have one base ruleset than it > makes sense to put that base rule in package.json, otherwise we can have > different base rules with jshintrc files at folder roots. > > When invoked from cli `jshint filename` will walk all the way up to the > filesystem root until it finds a config file (unless you set configurations > differently). Given that it's incredibly hard to get consensus on different > IDE preferences, I would shy away from any IDE specific benefits/problems. +1 > -----Original Message----- > From: Mark Koudritsky [mailto:[email protected]] > Sent: Wednesday, January 21, 2015 1:01 PM > To: [email protected] > Subject: Re: Usage of jscs & JSHint in Cordova > > I added he jscs file in cordova-lib some time ago but didn't enforce it in > npm test because that required more work in the code to get rid of the > remaining style errors. Would be glad if someone invests the effort to make > the code comply with the current (or modified) rules. > > Similar story for the spec files, they were excluded from the JShint check > because we didn't have the time/motivation to make them compliant with any > reasonable jshint settings. > > I don't have a strong opinion about what is better for jshint, a config > file or individual config lines in js files. One benefit of config comments > is that it works in editors that do real time jshinting, but ignore the > config files in parent dirs (I think Brackets jshint plugin was doing this > some time ago). > > I'm not sure if it's worth it moving the config file(s) up the dir, they > probably should live as siblings of the package.json > > > On Wed, Jan 21, 2015 at 3:16 PM, Murat Sutunc <[email protected]> > wrote: > > > Hi, > > I was curious about the jscs and jshint usage in cordova repos. Seems > > like in cordova-lib we currently have: > > > > - jscs rules in cordova-lib\cordova-lib > > > > - individual jshint rules on some js files under > > cordova-lib\cordova-lib > > > > - > > While jscs rules are set, it's currently not plugged into `npm test`. > > Do we have a policy in place to enforce these rules? If so I should > > add it to packages.json or just remove the config file. > > > > Regarding individual jshint rules on files, should we migrate to > > having one .jshintrc file on the base folder (and exclude > > node_modules). We can then add individual flags on files if they are > > necessary to do so and catch any potentially non-hinted files (ex. > > many files are non-hinted > > spec-cordova\*) According to CB-6973 the following jshint config can > > be the master rule: > > /* jshint node:true, bitwise:true, undef:true, trailing:true, > > quotmark:true, indent:4, unused:vars, latedef:nofunc */ > > > > Any thoughts? > > > > Thanks, > > Murat > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
