I find the jshint task super helpful when making changes to cordova-lib. Would love it if it appeared in the platforms as well!
On Mon, Feb 2, 2015 at 12:17 PM, Murat Sutunc <[email protected]> wrote: > Now that cordova-lib is done, I'm considering extending the jshint support > to individual platforms. Any concerns or thoughts? > > > On Jan 21, 2015, at 5:23 PM, Mark Koudritsky <[email protected]> wrote: > > > >> 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] > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
