Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting
I agree with Rob in terms of tooling and with Travis on rules.Any linting tool is fine with me as long as it does not break the rules we currently have set in Horizon. I believe the rules right now are general enough, so switching to eslint might not be an issue, but its something to look into. And we are still early in the JSCS stages, so this is actually opportune timing. I don't have a strong opinion on which tool so as long as it gets the job done and does not stall work in Horizon for liberty.-Michael Krotscheck krotsch...@gmail.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Michael Krotscheck krotsch...@gmail.comDate: 06/16/2015 12:30PMSubject: Re: [openstack-dev] [_javascript_] [horizon] [merlin] [refstack] _javascript_ LintingOn Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S travis.tr...@hp.com wrote:I think agreeing on rules is the bigger problem here and I dont think all the projects should have to agree on rules.I believe we agree there, mostly. I personally feel there is some benefit to setting some rules, likely published as an openstack linting plugin, which enforce things like "Do not use fuzzy versions in your package.json" and other things that make things unstable. That should be a very carefully reserved list of rules though.I've created an eslint configuration file that includes every single rule, it's high level purpose, and a link to the details on it, and provided it in a patch against horizon. The intent is that it's a good starting point from which to activate and deactivate rules that make sense for horizon.https://review.openstack.org/#/c/192327/Weve spent a good portion ofliberty 1 getting the code base cleaned up to meet the already adoptedhorizon rules and it is still in progress.As a side note, the non-voting horizon linting job for _javascript_ things is waiting for review here:https://review.openstack.org/#/c/16/My preference would be to see if we can use eslint to accomplish all of our currently adopted horizon rules [3][4] AND to also add in the angular specific plugin [1][2]. But we cant do this at the expense of the entire liberty release.Again, I agree. The patch I've provided above sets up the horizon eslint build, and adds about... 10K additional style violations. Since neither of the builds pass, it's difficult to see the difference, yet either way you should probably tweak the rules to match horizon's personal preferences.Michael __OpenStack Development Mailing List (not for usage questions)Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] [horizon] [merlin] [refstack] Javascript Linting
Just for the sake of clarity- did the Horizon team discuss the tool selection for JSCS with the greater community? I can't find anything on the dev list. Furthermore, there've been situations before (karma) where a patch was landed without appropriate upstream notifications and/or discussion, which then resulted in a lot of unnecessary work. Horizon isn't the only UI project anymore. While it's certainly the elephant in the room, that doesn't mean its decisions shouldn't be up to scrutiny. Michael On Tue, Jun 16, 2015 at 12:44 AM Rob Cresswell (rcresswe) rcres...@cisco.com wrote: So my view here is that I don’t particularly mind which plugin/ set of plugins Horizon uses, but the biggest deterrent is the workload. We’re already cleaning everything up quite productively, so I’m reluctant to swap. That said, the cleanup from JSCS/ JSHint should be largely relevant to ESLint. Michael, do you have any ideas on the numbers/ workload behind a possible swap? With regards to licensing, does this mean we must stop using JSHint, or that we’re still okay to use it as a dev tool? Seems that if the former is the case, then the decision is made for us. Rob From: Michael Krotscheck krotsch...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, 16 June 2015 00:36 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: - Horizon currently uses JSCS. - Refstack uses Eslint. - Merlin doesn't use anything. - StoryBoard (deprecated) uses eslint. - Nobody agrees on rules. *JSCS* JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. *JSHint* Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. *ESLint* ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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 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] [horizon] [merlin] [refstack] Javascript Linting
I’m copying and pasting from the other thread some info below. I think agreeing on rules is the bigger problem here and I don’t think all the projects should have to agree on rules. We’ve spent a good portion of liberty 1 getting the code base cleaned up to meet the already adopted horizon rules and it is still in progress. My preference would be to see if we can use eslint to accomplish all of our currently adopted horizon rules [3][4] AND to also add in the angular specific plugin [1][2]. But we can’t do this at the expense of the entire liberty release. ― My previously email below: 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 From: Rob Cresswell (rcresswe) rcres...@cisco.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Tuesday, June 16, 2015 at 1:40 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting So my view here is that I don’t particularly mind which plugin/ set of plugins Horizon uses, but the biggest deterrent is the workload. We’re already cleaning everything up quite productively, so I’m reluctant to swap. That said, the cleanup from JSCS/ JSHint should be largely relevant to ESLint. Michael, do you have any ideas on the numbers/ workload behind a possible swap? With regards to licensing, does this mean we must stop using JSHint, or that we’re still okay to use it as a dev tool? Seems that if the former is the case, then the decision is made for us. Rob From: Michael Krotscheck krotsch...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Tuesday, 16 June 2015 00:36 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: * Horizon currently uses JSCS. * Refstack uses Eslint. * Merlin doesn't use anything. * StoryBoard (deprecated) uses eslint. * Nobody agrees on rules. JSCS JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. JSHint Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. ESLint ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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] [horizon] [merlin] [refstack] Javascript Linting
On Tue, Jun 16, 2015 at 10:22 AM Tripp, Travis S travis.tr...@hp.com wrote: I think agreeing on rules is the bigger problem here and I don’t think all the projects should have to agree on rules. I believe we agree there, mostly. I personally feel there is some benefit to setting some rules, likely published as an openstack linting plugin, which enforce things like Do not use fuzzy versions in your package.json and other things that make things unstable. That should be a very carefully reserved list of rules though. I've created an eslint configuration file that includes every single rule, it's high level purpose, and a link to the details on it, and provided it in a patch against horizon. The intent is that it's a good starting point from which to activate and deactivate rules that make sense for horizon. https://review.openstack.org/#/c/192327/ We’ve spent a good portion of liberty 1 getting the code base cleaned up to meet the already adopted horizon rules and it is still in progress. As a side note, the non-voting horizon linting job for javascript things is waiting for review here: https://review.openstack.org/#/c/16/ My preference would be to see if we can use eslint to accomplish all of our currently adopted horizon rules [3][4] AND to also add in the angular specific plugin [1][2]. But we can’t do this at the expense of the entire liberty release. Again, I agree. The patch I've provided above sets up the horizon eslint build, and adds about... 10K additional style violations. Since neither of the builds pass, it's difficult to see the difference, yet either way you should probably tweak the rules to match horizon's personal preferences. 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] [horizon] [merlin] [refstack] Javascript Linting
So my view here is that I don’t particularly mind which plugin/ set of plugins Horizon uses, but the biggest deterrent is the workload. We’re already cleaning everything up quite productively, so I’m reluctant to swap. That said, the cleanup from JSCS/ JSHint should be largely relevant to ESLint. Michael, do you have any ideas on the numbers/ workload behind a possible swap? With regards to licensing, does this mean we must stop using JSHint, or that we’re still okay to use it as a dev tool? Seems that if the former is the case, then the decision is made for us. Rob From: Michael Krotscheck krotsch...@gmail.commailto:krotsch...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Tuesday, 16 June 2015 00:36 To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: [openstack-dev] [javascript] [horizon] [merlin] [refstack] Javascript Linting I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: * Horizon currently uses JSCS. * Refstack uses Eslint. * Merlin doesn't use anything. * StoryBoard (deprecated) uses eslint. * Nobody agrees on rules. JSCS JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. JSHint Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. ESLint ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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] [horizon] [merlin] [refstack] Javascript Linting
JSCS in Horizon has been extended with the John Papa style guidelines to enforce consistent angularjs code style*. It's no longer just a findbug tool. I don't have time to investigate - can ESLint perform the same role for Horizon? Current Horizon activity involves a whole lot of bringing code into line with that style (and other JSCS check fails). Richard * https://review.openstack.org/#/c/181311/ On Tue, 16 Jun 2015 at 09:40 Michael Krotscheck krotsch...@gmail.com wrote: I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: - Horizon currently uses JSCS. - Refstack uses Eslint. - Merlin doesn't use anything. - StoryBoard (deprecated) uses eslint. - Nobody agrees on rules. *JSCS* JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. *JSHint* Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. *ESLint* ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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 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] [horizon] [merlin] [refstack] Javascript Linting
On 16 June 2015 at 16:21, Richard Jones r1chardj0...@gmail.com wrote: JSCS in Horizon has been extended with the John Papa style guidelines to enforce consistent angularjs code style*. It's no longer just a findbug tool. I don't have time to investigate - can ESLint perform the same role for Horizon? Yes - https://twitter.com/john_papa/status/574074485944385536 [I haven't dug into the details, but thats a tweak announcing eslint john papa support]. -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] [horizon] [merlin] [refstack] Javascript Linting
Sorry, wrong patch. That one added the style requirement to the project contribution guidelines. This is the one that added the .jscsrc config: https://review.openstack.org/#/c/185725/ On Tue, 16 Jun 2015 at 14:21 Richard Jones r1chardj0...@gmail.com wrote: JSCS in Horizon has been extended with the John Papa style guidelines to enforce consistent angularjs code style*. It's no longer just a findbug tool. I don't have time to investigate - can ESLint perform the same role for Horizon? Current Horizon activity involves a whole lot of bringing code into line with that style (and other JSCS check fails). Richard * https://review.openstack.org/#/c/181311/ On Tue, 16 Jun 2015 at 09:40 Michael Krotscheck krotsch...@gmail.com wrote: I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: - Horizon currently uses JSCS. - Refstack uses Eslint. - Merlin doesn't use anything. - StoryBoard (deprecated) uses eslint. - Nobody agrees on rules. *JSCS* JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. *JSHint* Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. *ESLint* ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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 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] [horizon] [merlin] [refstack] Javascript Linting
I'm restarting this thread with a different subject line to get a broader audience. Here's the original thread: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066040.html The question at hand is What will be OpenStack's javascript equivalent of flake8. I'm going to consider the need for common formatting rules to be self-evident. Here's the lay of the land so far: - Horizon currently uses JSCS. - Refstack uses Eslint. - Merlin doesn't use anything. - StoryBoard (deprecated) uses eslint. - Nobody agrees on rules. *JSCS* JSCS Stands for JavaScript CodeStyle. Its mission is to enforce a style guide, yet it does not check for potential bugs, variable overrides, etc. For those tests, the team usually defers to (preferred) JSHint, or ESLint. *JSHint* Ever since JSCS was extracted from JSHint, it has actively removed rules that enforce code style, and focused on findbug style tests instead. JSHint still contains the Do no evil license, therefore is not an option for OpenStack, and has been disqualified. *ESLint* ESLint's original mission was to be an OSI compliant replacement for JSHint, before the JSCS split. It wants to be a one-tool solution. My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I understand that this will mean some work by the Horizon team to bring their code in line with a new parser, however I personally consider this to be a good thing. If the code is good to begin with, it shouldn't be that difficult. This thread is not there to argue about which rules to enforce. Right now I just want to nail down a tool, so that we can (afterwards) have a discussion about which rules to activate. 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] [horizon] [merlin] [refstack] Javascript Linting
On 16 June 2015 at 11:36, Michael Krotscheck krotsch...@gmail.com wrote: ... My personal opinion/recommendation: Based on the above, I recommend we use ESLint. My reasoning: It's one tool, it's extensible, it does both codestyle things and bug finding things, and it has a good license. JSHint is disqualified because of the license. JSCS is disqualified because it is too focused, and only partially useful on its own. I welcome our new ESLint overlords. -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
