Open Stack

Michael,

Maybe you should start this thread again with a link to the full thread but add all the projects into subject (e.g. [horizon]).  Otherwise quite a few people may not see it.

You are right that the John Papa guidelines are definitely targeted at angular and not general style.  They are community driven (and endorsed by the angular team).  We discussed it quite a bit at the summit and we agreed that we wanted to spend less time arguing personal preferences for formatting in patches and his guidelines helped to do that for angular style.

Thanks,
Travis

From: Michael Krotscheck <krotscheck at gmail.com<mailto:krotscheck at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, June 10, 2015 at 9:29 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [javascript] Linters



On Tue, Jun 9, 2015 at 3:37 PM Robert Collins <robertc at robertcollins.net<mailto:robertc at robertcollins.net>> wrote:
On 10 June 2015 at 04:01, Michael Krotscheck <krotscheck at gmail.com<mailto:krotscheck at gmail.com>> wrote:
> 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.
...
> 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?

Yes, I think this should live in openstack/requirements.

bower.json is clearly js specific; package.json isn't AFAICT - can you
give me some sane pointers to go level up on that?

There are two package managers in the JavaScript world right now, one that focuses on node.js/server dependencies (karma, lint, express, etc), and one that focuses on in-browser dependencies (angular, bootstrap, etc). They're both required for thick browser clients, but for server apps you only really need package.json

https://docs.npmjs.com/files/package.json
https://github.com/stackforge/refstack/blob/master/refstack-ui/package.json
https://github.com/angular-ui/bootstrap/blob/master/package.json
https://github.com/openstack/horizon/blob/master/package.json

In the absence of information I'm assuming we should make a subdir
'js' and put bower.json and package.json in there (and do the same for
the python things in a subdir called python for symmetry, though
backwards compat and tooling considerations may mean that we have to
prepare for that. The reason being that if package.json is js
specific, its just confusing to have it live at the top level. Also we
may want to call them global-$thing, since if we do have js in the
requirements repo itself at some point, it would be good not to
conflict on names.

FYI, it looks like the monasca team may want to start doing similar things with Java. More information after I hunt them down this morning :)

I'm not at all sure that update.py should handle the json files per
se; will the policy for those files be the same as we use for python?

Add linting rule sets to this list, contained either in .jscsrc or .eslintrc. Javascript does not have the privilege of pep8 being baked into the language tooling, so we have to sync it ourselves.

If not it might be cleaner to have a new entry point. OTOH I'll need
to look closely at a few real {bower,package}.json files to proffer an
useful opinion. [Perhaps you covered this in IRC - it didn't come
through in your summary].

It depends on what you think update.py is supposed to do. If I look at that repository, I would argue that the purpose is to "Synchronize common files and properties across registered openstack projects". In this case, a "requirement" is defined as something required to meet a minimum set of project "sanity" standards.

Also, I'm in the middle of rearranging update.py to handle PEP 426 and so we should probably coordinate so we don't tromp on each other.

Do you have a patch?

Michael