Well, it looks like everyone has disqualified jslint and jshint, so let's just make a decision there and remove them from the running. Unless I hear a compelling reason to use something that has the infamous "do no evil" license in it, let's dump it.
The John Papa styles seem sane, and though I disagree with them, I'd be ok using them. Putting everything in a closure is an old standard that has usually just annoyed me, since it's one of those things about javascript that _shouldn't_ have to be explicit, but no language is perfect ;). The existing eslint stylesheets that exist in StoryBoard and others were written with PEP8 in mind, in order to facilitate readability between our languages, however I am also a strong believer in treating JavaScript on equal terms with other languages. Also, John papa seems to have more opinions about angular apps than javascript in general, so I propose this rule for OpenStack going forward: 1- If the John Papa rules have an opinion, use that. 2- Otherwise, use pep8 (where applicable). 3- Otherwise, check to see if there's a thing in hacking. 4- If it's in none of those, we'll address it on a case by case basis. The main reasons for this is that I simply do not want to have an argument about spaces vs. tabs. The arguments about PEP8 have already been had, and the benefits of a language-wide enforced style are simple: We can argue about more important things! :). Let's assume a week of commentary on the above. As for how this is synchronized, a brief discussion in the infra channel proposed that we put global javascript requirements in the global-requirements repo, and then update the update.py script in that repo to also handle bower.json and package.json. Then, if we build an eslint/jscs plugin similar to our hacking rules, we can just update that when we want to modify the linting rules. Any objections? With regards to JSCS vs. Eslint, I feel that we actually have to use both to decide which is better: Once we set up the rules side by side and try to apply them against a project, a clear winner will emerge. Does anyone want to volunteer to put together a spreadsheet of all the rules from John Papa and pep8 that we'd like to enforce, and the appropriate rule in eslint and/or jscs that applies? Michael On Mon, Jun 8, 2015 at 9:57 PM Tripp, Travis S <[email protected]> wrote: > We¹ve adopted the John Papa style guide for Angular in horizon [0]. On > cursory inspection ES lint seems to have an angular specific plugin [1] > that could be very useful to us, but we¹d need to evaluate it in depth. It > looks like there was some discussion on the style guide on this not too > long ago [2]. The jscs rules we have [3] are very generic code formatting > type rules that are helpful, but don't really provide any angular specific > help. Here are the jshint rules [4]. It would be quite nice to put all > this goodness across tools into a single tool configuration if possible. > > [0] > http://docs.openstack.org/developer/horizon/contributing.html#john-papa-sty > le-guide > <http://docs.openstack.org/developer/horizon/contributing.html#john-papa-style-guide> > [1] https://www.npmjs.com/package/eslint-plugin-angular > [2] https://github.com/johnpapa/angular-styleguide/issues/194 > [3] https://github.com/openstack/horizon/blob/master/.jscsrc > [4] https://github.com/openstack/horizon/blob/master/.jshintrc > > On 6/8/15, 9:59 PM, "gustavo panizzo (gfa)" <[email protected]> wrote: > > > > > > >On 2015-06-06 03:26, Michael Krotscheck wrote: > >> Right now, there are several JS linters in use in OpenStack: JSHint, > >> JSCS, and Eslint. I really would like to only use one of them, so that I > >> can figure out how to sanely share the configuration between projects. > >> > >> Can all those who have a strong opinion please stand up and state their > >> opinions? > > > >what about https://bitbucket.org/dcs/jsmin/ it's license is free > > > > > >-- > >1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 > > > >keybase: http://keybase.io/gfa > > > >__________________________________________________________________________ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: > [email protected]?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
