Re: [openstack-dev] [javascript] Linters
On Tue, Jun 9, 2015 at 3:37 PM Robert Collins robe...@robertcollins.net
wrote:
On 10 June 2015 at 04:01, Michael Krotscheck krotsch...@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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
On 11 June 2015 at 03:29, Michael Krotscheck krotsch...@gmail.com wrote:
On Tue, Jun 9, 2015 at 3:37 PM Robert Collins robe...@robertcollins.net
wrote:
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
Ok, thanks. So within that only the *Dependencies fields seem
interesting, no? With our multiple ways of expressing requirements in
Python we fold all the things that might be in any of them into
global-requirements.txt. I think we're going to want to do the same
here : e.g. /not/ literal package.json, but something very similar -
say one with all the project specific metadata missing and just a
dependencies sub-dict.
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 :)
And swift w/go. Yes.
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.
Ah so - I don't think that linting rule sets fit global-requirements
at all. pep8 (the tool) isn't baked into the language tooling, it was
created and maintained by a third party based on PEP 8 (the
specification), and is more opinionated than PEP8 was ever intended to
be (and in fact PEP8 isn't intended to apply outside of the stdlib,
even though folk like us use it as a starting point).
The set of folk that are interested in requirements management
(distributors want a control point to review licensing and whether its
in their distro, the community consensus also cared about maturity,
supportability and Python3 readiness)... and the set of folk
interested in linting configuration are very different and IMO it
makes no sense to squash them together.
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.
There are two related bits of tooling. We have openstack/requirements
which is a central place for dependency ('requirements' inspired from
requirements.txt and the -r parameter to pip). And we have a separate
tool that runs scripts *like* requirements/update.py and proposes
things from them:
project-config/jenkins/scripts/propose_update.sh
project-config/jenkins/scripts/propose_translation_update_horizon.sh
project-config/jenkins/scripts/propose_translation_update_manuals.sh
project-config/jenkins/scripts/propose_translation_update_django_openstack_auth.sh
project-config/jenkins/scripts/propose_translation_update.sh
So - we have a bunch of places where we synchronise things across
projects in various ways. The code in openstack/requirements today is
all and only about dependency management. I think it should stay that
way. Adding js and other languages makes a tonne of sense; whether the
/code/ involved in adding those languages should be Python or $other
language, and whether it should be added to the existing update.py or
a new entry point in the same project - those are two questions whose
answers are not entirely clear to me.
By 'same policy' earlier - let me expand: the policy update.py
implements for Python today is:
0: global requirements are defined in global-requirements.txt
1: projects MUST NOT have dependencies not present in global-requirements.
2: dependencies must be an exact textual match for those in global-requirements
3: project requirements are in requirements.txt or test-requirements.txt
Adding JS to update.py specifically involves:
- abstracting out the location and parsing of requirements
-
Re: [openstack-dev] [javascript] Linters
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 krotsch...@gmail.commailto:krotsch...@gmail.com
Reply-To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, June 10, 2015 at 9:29 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [javascript] Linters
On Tue, Jun 9, 2015 at 3:37 PM Robert Collins
robe...@robertcollins.netmailto:robe...@robertcollins.net wrote:
On 10 June 2015 at 04:01, Michael Krotscheck
krotsch...@gmail.commailto:krotsch...@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
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
Hey there, Gustavo- JSMin's a minifier, not a linter, yes? Unless I'm wrong, we're discussing the enforcement of code style rather than the concatenation step in our build, and thus jsmin's not really in the running. Once we _do_ talk about how we assemble javascript, I'm sure JSMin will have a strong following :) Michael On Mon, Jun 8, 2015 at 9:02 PM gustavo panizzo (gfa) g...@zumbi.com.ar 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
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 travis.tr...@hp.com 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) g...@zumbi.com.ar 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
The more I think about this, the more I think my ideas are dumb. John Papa has very opinionated guides on how an _angular_ application should be structured. Openstack's linting must be framework agnostic, because we can't predict which frameworks may or may not be used. For example, there is a good case for a framework-agnostic API library for [Insert API Here]. So, let's just start with the Google Style Guidelines, and let projects use plugins (like eslint-angular) to support additional project guidelines. Michael On Tue, Jun 9, 2015 at 9:01 AM Michael Krotscheck krotsch...@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. 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 travis.tr...@hp.com 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) g...@zumbi.com.ar 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing
Re: [openstack-dev] [javascript] Linters
On 10 June 2015 at 04:01, Michael Krotscheck krotsch...@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?
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.
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?
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].
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.
-Rob
--
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
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 [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) g...@zumbi.com.ar 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
On Fri, Jun 05, 2015 at 07:26:24PM +, 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? Michael jshint: still non-free license [1] eslint seems to require to sign a CLA, if we come across an issue and were going to fix that. jscs seems to be the utility, cool kids are using. As expected, it requires node. It has seen 3 releases within 3 months, or 5 in 4 months. My question here would be: how are we going to handle changes here over a release (and how to keep this running on the gate for released versions)? Matthias [1] https://github.com/jshint/jshint/blob/master/src/jshint.js#L19 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Matthias Runge mru...@redhat.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [javascript] Linters
On Mon, Jun 8, 2015 at 1:59 AM Matthias Runge mru...@redhat.com wrote: jshint: still non-free license [1] Yep! Ergo, we can't really use it. eslint seems to require to sign a CLA, if we come across an issue and were going to fix that. So does the python foundation, I'm not really worried about it. jscs seems to be the utility, cool kids are using. As expected, it requires node. It has seen 3 releases within 3 months, or 5 in 4 months. Google trends disagrees with this assertion: https://www.google.com/trends/explore#q=eslint%2C%20jscs%2C%20jshint%2C%20jslintcmpt=qtz= Also, as a random aside, I have read things On The Internet (tm) that say that eslint is better about doing PMD things like scope variable overrides and unused parameters. Not having used JSCS, I can't really comment. My question here would be: how are we going to handle changes here over a release (and how to keep this running on the gate for released versions)? http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev The required version of eslint is actually defined per project, in package.json. As long as the project does NOT use fuzzy version matching (~1.x.x), the build should remain reliable. Furthermore, all 'lint' builds are abstracted behind the `npm run lint` command, and is definable by project, so specific changes to the linting configuration are committed to the codebase. Here's an example: https://review.openstack.org/#/c/185711/5/refstack-ui/package.json Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [javascript] Linters
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? Michael __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
