14:00:33 <krotscheck> #startmeeting javascript
14:00:39 <openstack> Meeting started Wed Jun 22 14:00:33 2016 UTC and is due to finish in 60 minutes.  The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:39 <krotscheck> Good morning everyone!
14:00:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:43 <openstack> The meeting name has been set to 'javascript'
14:00:51 <betherly> o/
14:00:56 <krotscheck> Agenda:
14:00:58 <SotK> o/
14:00:58 <krotscheck> #link https://etherpad.openstack.org/p/javascript-meeting-2016-06-22
14:01:16 <Zara> o/
14:01:24 <timothyb89> hello!
14:01:46 <krotscheck> #topic Core elections!
14:01:48 <jaranovich> hi!
14:02:13 <msmol> hello all
14:02:19 <krotscheck> betherly, SotK, Zara, timothyb89, jaranovich, msmol : Hi everyone!
14:02:23 <vkramskikh> hi
14:02:25 <SotK> hi!
14:02:28 <azemlyanov> hello!
14:02:30 <Zara> hi krotscheck!
14:02:44 <krotscheck> At the moment I'm the only core for js-openstack-lib and js-generator-openstack, and, well, I'd like not to be.
14:03:10 <krotscheck> I've gone through and picked all the people who have, to date, performed code reviews on those project.
14:03:15 <krotscheck> And I nominate all of them!
14:03:26 <krotscheck> With two caveats:
14:03:39 <krotscheck> 1- they have to want it (aka- go through the list on the etherpad and remove yourself if you don't want it)
14:03:52 <krotscheck> (or, if you're not here, I'll reach out to you later)
14:04:22 <krotscheck> 2- We agree on a reasonable baseline for the # of reviews.
14:06:01 <Zara> okay, I'm gonna remove myself, since I don't think I know enough, and also don't think I'll be able to give it the attention it warrants
14:06:12 <krotscheck> Zara: That's fair.
14:06:19 <krotscheck> Does anyone disagree with me setting the bottom bar for reviews at > 2?
14:06:20 <jprivard> same for me, I'm brand new in this :)
14:06:28 <jprivard> fine by me
14:06:43 <Zara> I'm happy to +1 stuff. if later on there's a core-shortage, maybe we can talk xD
14:06:50 <Zara> but yeah, not a good idea for anyone yet.
14:07:19 <msmol> for what it's worth, that all sounds good to me
14:07:22 <betherly> sounds good to me
14:07:30 <vkramskikh> i'm fine with it
14:07:37 <krotscheck> Alrightey, so that sets the nominee list for js-openstack-lib to vkramskikh.
14:07:43 <krotscheck> vkramskikh: Would you like to be core?
14:07:59 <vkramskikh> krotscheck: yes I would, I'm really interested in the project
14:08:04 <krotscheck> all: does anyone disagree?
14:08:10 * krotscheck waits 30 seconds
14:08:58 <krotscheck> Alrightey, core #1 is vkramskikh!
14:09:03 <Zara> \o/
14:09:06 <vkramskikh> woohoo
14:09:08 <azemlyanov> +1
14:09:15 <jaranovich> congrats, vkramskikh!
14:09:22 <nbogdanov> yay!
14:09:26 <krotscheck> Next: js-generator-openstack
14:09:26 <SotK> congrats!
14:09:56 <krotscheck> The current nominee list are yujunz (not present, late in shanghai), betherly, and notmars.
14:10:06 <krotscheck> (notmars is bruno).
14:10:24 <krotscheck> betherly: Would you like to be core?
14:10:29 <cardeois> he's not present too early for him
14:10:37 <krotscheck> cardeois: What's his timezone?
14:10:43 <betherly> congrats vkramskikh :)
14:10:43 <cardeois> (for notmars)
14:11:06 <betherly> im happy to be
14:11:07 <cardeois> EST but he's not a morning guy
14:11:13 <krotscheck> cardeois: I can relate.
14:11:27 <krotscheck> Alright, does anyone have disagreements with betherly as a core for generator-openstack?
14:11:42 <jprivard> I'm all for it
14:12:21 <krotscheck> Let's just do all at once: Does anyone have reservations about notmars, betherly, and yujunz being core? I'll wait 30 seconds, and check with them once they come online.
14:12:27 * krotscheck waits 30 seconds
14:13:12 <krotscheck> ALrightey!
14:13:15 <krotscheck> congrats betherly!
14:13:19 * krotscheck will ping the others
14:13:19 <Zara> yaaaaaaay! congratulations, betherly!
14:13:24 <betherly> thanks :)
14:13:25 <jaranovich> congrats betherly :)
14:13:29 <krotscheck> #action krotscheck Add vkramskikh as core to js-openstack-lib
14:13:35 <Zara> (and hopefully congratulations yujunz and notmars, will see!)
14:13:37 <vkramskikh> congrats :)
14:13:38 <krotscheck> #action krotscheck add betherly as core to js-generator-openstack
14:13:55 <SotK> congrats betherly!
14:13:56 <krotscheck> #action reach out to notmars and yujunz for their consent as project cores on js-generator-openstack
14:14:11 <krotscheck> Who would like to be responsible for updating the meeting chairs on eavesdrop?
14:14:28 <krotscheck> #action krotscheck reach out to notmars and yujunz for their consent as project cores on js-generator-openstack
14:15:00 <krotscheck> If nobody volunteers, I'm going to nominate vkramskikh to do that :D
14:15:16 <vkramskikh> ok, just please explain how to do that :)
14:15:38 <krotscheck> vkramskikh: Submnit a patch to the openstack-meetings repository that updates the javascript-sdk meeting chairs
14:16:03 <krotscheck> #action vkramskikh Update javascript meeting chairs in openstack-meetings
14:16:16 <krotscheck> #topic js-openstack-lib design: Isomorphism
14:16:53 <krotscheck> "Isomorphic" in this case means a library that works both in the browser and in a node.js runtime.
14:17:11 <vkramskikh> I think it was already discussed in #openstack-javascript and everybody agreed that it should be isomorphic :)
14:17:15 <krotscheck> I have no experience on how to do this successfully, and therefore can't really speak to how much additional effort it might be.
14:17:25 <cardeois> Yes I think it's a must have
14:17:39 <krotscheck> At this time, I've only heard demand for browser clients though.
14:17:46 <vkramskikh> I also don't have much experience, but don't see any obstacles
14:17:49 <azemlyanov> any pure JS lib is isomorphic
14:18:11 <krotscheck> azemlyanov: Are you volunteering to build our HTTP request abstraction? ;D
14:18:25 <azemlyanov> fetch API?
14:18:44 <krotscheck> azemlyanov: http://caniuse.com/#search=fetch
14:18:55 <krotscheck> 53% support in browsers.
14:19:00 <krotscheck> One more note though:
14:19:11 <azemlyanov> I heard vkramskikh had desire to do it
14:19:12 <krotscheck> We only support what we can test, and IE/Safari are not open source.
14:19:16 <krotscheck> So we cannot support them.
14:19:23 <msmol> jQuery for http?
14:19:37 <vkramskikh> yes I do, I'll express my thoughts on it when time comes (we have this item in agenda)
14:19:40 <krotscheck> In other words, the fetch api is available and supported on all the browsers we can test.
14:19:44 <azemlyanov> fetch API is modern, plofill for obsolete browsers
14:19:47 <cardeois> Well I think there is fetchAPI implementations in npm
14:19:57 <cardeois> to support browser not supporting them
14:20:23 <krotscheck> Alright, we'll table this for the later discussion. At the moment, all I hear is a devil's advocate for isomorphism (myself), and i'm jsut doing that because nobody else is.
14:20:23 <cardeois> or what azemlyanov said
14:20:32 <krotscheck> DOes anyone disagree?
14:20:45 <krotscheck> (Does anyone disagree with openstack-lib's need to be isomorphic?)
14:21:18 <krotscheck> #agreed js-openstack-lib should be isomorphic.
14:21:39 <krotscheck> #topic js-openstack-lib design: ES5 or ES6 (ES2015)
14:21:52 <vkramskikh> I think we should definitely start using complete ES6 syntax, since latest node.js and Chrome/Firefox support almost all ES6 features, and Babel is quite mature. As for non-syntax stuff like Proxies, I think we should stick to ES6 features that could be polyfilled to run in ES5 envs - there is still quite big share of node 0.x, IE <11, Safari, etc. I've also heard that it's not possible to upload ES6 code to NPM, so we need to use
14:21:52 <vkramskikh> Babel anyway.
14:22:06 <msmol> +1
14:22:11 <azemlyanov> ES5 is pretty old, no classes, no iterators, destructuring
14:22:17 <betherly> I agree with vkramskikh. Was just typing that I think ES6 should be the direction we go in
14:22:49 <betherly> sets the right precedence moving forwards as well
14:23:04 <cardeois> I think ES6 could be used but for ES5 compatibily, we should provide a ES5 compiled version of our lib to people using our lib. As compiling with babel takes about 400MB of node_modules
14:23:04 <krotscheck> My only ask is that we ship all versions of the library in our release artifacts, though the default will likely be node.js ES5 transpiled.
14:23:33 <krotscheck> cardeois: Whoa, 400MB? That's ridiculous!
14:23:45 <betherly> ugh :/
14:23:52 <tsufiev> hey, folks
14:24:00 <krotscheck> tsufiev: Hi there!
14:24:04 <vkramskikh> modern Babels 6.8+ are quite "slim" (about 50mb)
14:24:06 <cardeois> yeah it is, I discovered that with babel using ES2015, but maybe there's a better way
14:24:16 <krotscheck> This might be related:
14:24:16 <krotscheck> #link https://blog.nodeswat.com/what-i-learned-from-analysing-1-65m-versions-of-node-js-modules-in-npm-a0299a614318
14:24:19 <tsufiev> do you know that meeting places are contradictory in https://etherpad.openstack.org/p/javascript-meeting-2016-06-22 vs https://etherpad.openstack.org/p/javascript-meeting-agenda ;)?
14:24:28 <cardeois> oh cool vkramskikh will try that
14:24:53 <krotscheck> tsufiev: Good catch, thanks! Fixed.
14:25:12 <krotscheck> It doesn't sound like anyone disagrees with ES6 as the base language.
14:25:24 <msmol> Can't we just supply the ES6 version and let people transpile it themselves in their projects should they choose?
14:25:26 <krotscheck> It also sounds like generator-openstack is stuck in ES5 land for the time being.
14:25:54 <azemlyanov> es5 is subset of es6
14:26:00 <krotscheck> msmol: I don't think so. In a native node app, engineers are going to assume that require('openstack-lib') will "just work" (tm)
14:26:06 <cardeois> Well vkramskikh was saying we can't upload ES6 to NPM is that true?
14:26:13 <vkramskikh> msmol: we need to research about NPM's restriction for ES6 code - AFAIK it just doesn't allow to upload non-transpiled ES6 code
14:26:18 <krotscheck> And I don't know if requirejs supports that...
14:26:33 <azemlyanov> npm does't care
14:26:43 <krotscheck> Does requirejs care?
14:27:07 <krotscheck> Sounds like we need some research.
14:27:08 <vkramskikh> requirejs can parse es6 code, but it's really painful to setup all that properly
14:27:20 <msmol> Hmm, I wasn't aware of that npm restriction, and as for native node apps, node supports ES6... there is even less reason to use ES5 in a node app than in the browser
14:27:21 <cardeois> Yeah maybe to avoid complex setup for people using the lib I think it's better to provide the transpiled version
14:27:23 <vkramskikh> with babel plugin which is not officially supporte
14:27:24 <vkramskikh> d
14:27:25 <azemlyanov> requirejs is going away nowadays
14:27:30 <timothyb89> to my knowledge there's no real issues with es6 in npm, though it's common to flag a project as es6-supported using a 'js:next' flag instead of 'main' in package.json
14:27:46 <timothyb89> (instead of / in addition to)
14:28:24 <cardeois> ok then we could eventually provide both if we can
14:28:24 <timothyb89> for example d3 is es6 and also npm published: https://github.com/d3/d3-format/blob/master/package.json
14:28:58 <azemlyanov> I had no problems with es6 and es5 is a single npm package
14:29:26 <krotscheck> azemlyanov: That's encouraging.
14:29:34 <krotscheck> We can set the engine flag in the package as well, right?
14:29:47 <krotscheck> How much of ES6 is supported by Node4 LTS?
14:29:55 <azemlyanov> many npm packages have 'dist' folder with minified or customized versions
14:29:59 * krotscheck remembers the answer to that being "not much"
14:30:09 <vkramskikh> https://kangax.github.io/compat-table/es6/ about a half
14:30:24 <krotscheck> #link https://kangax.github.io/compat-table/es6/
14:30:35 <krotscheck> Well, looks like we'd have to transpile anyway until we shift to Node6 LTS
14:30:50 <vkramskikh> 50% for node4 vs 93% for node6
14:31:01 <azemlyanov> quite poor support. node v6 is some >95%
14:31:26 <krotscheck> SO, it sounds like we're trying to get to as much of ES6 as possible
14:31:44 <cardeois> agreed
14:31:48 <krotscheck> However we have the added constraint that infra right now only supports Node4, and is unlikely to upgrade in the Newton cycle.
14:32:26 <krotscheck> Meaning we'd have to polyfill/shim/transpile anyway
14:32:39 <msmol> so then how will we test the non-transpiled version?
14:32:54 <krotscheck> msmol: Good question.
14:33:02 <vkramskikh> probably we won't
14:33:08 <krotscheck> We could teach infra how to do nodeenv.
14:34:05 <krotscheck> The nodejs install right now exists in an on-demand infra macro. We could add a new one that installs Node6, and parameterize it in some way
14:34:06 <cardeois> I guess if we assume babel is doing its job correctly, we could only test the transpiled version until a better node version is available
14:34:22 <krotscheck> cardeois: True, but then our coverage metrics are going to be meaningless.
14:34:45 <vkramskikh> krotscheck: why?
14:35:13 <krotscheck> vkramskikh: We'd have to run instanbul's code annotation first, then pipe it through the transpiler.
14:35:38 <krotscheck> I'm not confident that the transpiler won't munge and destroy the code annotations.
14:36:17 <vkramskikh> research is also needed here, but I believe there is a solution for this
14:36:25 <vkramskikh> both babel and istanbul are quite popular
14:36:48 <cardeois> vkramskikh: agreed
14:36:50 <cardeois> Btw what test framework do we want to use? (or should we have a different topic about it?)
14:37:17 <krotscheck> cardeois: Probably a different topic.
14:37:35 <krotscheck> Ok, so we need more research. We already have a spec up for review here: https://review.openstack.org/#/c/332458/
14:37:38 <krotscheck> #link https://review.openstack.org/#/c/332458/
14:37:59 <krotscheck> That's probably the best place to leave comments, reviews, and updates. vkramskikh, would you like to take on the research? YOu can modify the spec directly if you'd like.
14:38:20 <vkramskikh> yes I would
14:38:29 <cardeois> #link https://onsen.io/blog/mocha-chaijs-unit-test-coverage-es6/
14:38:41 <cardeois> seems like it's possible
14:38:43 <krotscheck> vkramskikh: excellent. I'll be able to provide any necessary support vis-a-vis infra.
14:39:40 <krotscheck> #action vkramskikh Research ES6 transpiling options with regards to Node4, Node6, npm publishing, and update spec.
14:39:56 <krotscheck> Overall I think we're agreed that we want as much ES6 as possible.
14:40:02 <krotscheck> #agreed As much ES6 as possible.
14:40:17 <krotscheck> I'd like to move on, any other comments on this topic?
14:40:39 <jprivard> none on my side
14:40:53 <krotscheck> #topic js-openstack-lib design: What is server interaction approach?
14:40:58 <vkramskikh> I think we should use fetch() to interact with OpenStack services. fetch() is a modern XMLHTTPRequest with frendlier interface, which is supported by majority of the browsers and easily polyfillable. For node.js there are a few modules that implement fetch() interface, such as https://github.com/bitinn/node-fetch and https://github.com/matthew-andrews/isomorphic-fetch . I also think there should be mechanism to override/specify cus
14:40:59 <vkramskikh> tom request function, which must implement fetch() interface - I think this mechanism should be used for node.js envs to specify node-fetch or isomorphic-fetch. I'm going to write a spec for this.
14:41:45 <azemlyanov> fetch polyfills are available everywhere
14:42:30 <krotscheck> Can the polyfill be handled in the transpiler?
14:43:13 <vkramskikh> don't think polyfill has anything to do with the transpiler - it's just a module/js file which can be included in the project to support older browsers
14:43:32 * larainema late, read back the log
14:43:48 <vkramskikh> https://review.openstack.org/#/c/331772/ here's how we switched to fetch in fuel
14:44:05 <vkramskikh> https://review.openstack.org/#/c/331772/1/webpack.config.js that's what was necessary to add polyfill to the project
14:44:16 <krotscheck> vkramskikh: It's not browsers I'm concerned about. It's browsers vs. node.
14:44:39 <msmol> there's also superagent which is a quite popular project supporting both browser + node
14:45:04 <vkramskikh> nothing different here - transpliers are usually configured not to mangle non-project code
14:45:24 <krotscheck> vkramskikh: THe example you gave me a few days ago had the line "require('node-fetch')" in it.
14:45:30 <krotscheck> Is that not necessary?
14:46:00 <vkramskikh> yes it is, but I still don't understand what it has to do with transpilers :)
14:46:26 <krotscheck> vkramskikh: Well, first of all, you're making the assumption that we're using webpack.
14:46:34 <vkramskikh> superagent seems to be quite popular, worth researching
14:46:35 <krotscheck> That hasn't really been decided yet.
14:47:04 <krotscheck> It might just be the projec tname. To me, "node-fetch" says "This is a library designed to be run in a node runtime, and if loaded into a browser it will fail spectacularly"
14:47:22 <krotscheck> Hi there, larainema!
14:47:23 <vkramskikh> yes, but that's yet another thing that has nothing to do either with transpilers and polyfills :)
14:47:37 <vkramskikh> they are quite independent
14:47:49 <krotscheck> vkramskikh: We can't get the transpiler to automatically add node-fetch so we don't have to require() it?
14:47:50 <vkramskikh> I think I could explain in more thoroughly in the spec
14:47:53 <azemlyanov> orthogonal ;-)
14:47:56 <krotscheck> That's probably a good idea.
14:48:13 <krotscheck> I guess the real question I'm asking is: What runtime will our original source code target.
14:48:17 <msmol> isomorphic-fetch: https://github.com/matthew-andrews/isomorphic-fetch just found on google, no idea of it's quality
14:50:01 <cardeois> krotscheck: what do you mean runtime?
14:50:37 <krotscheck> cardeois: It's with regards to node-fetch style modules. If the library's isomorphic, we can't use those.
14:50:59 <krotscheck> We could use the one msmol just found, or adapt our own.
14:51:20 <cardeois> Yeah I guess we could do some research about it
14:51:29 <azemlyanov> it's rather build process to determine runtime and external deps
14:51:36 <krotscheck> Or, maybe, there's a compilation step that says "Oh, you're using fetch(), but your target language/runtime doesn't support it, lemme add a polyfill for you"
14:51:37 <vkramskikh> I think for node there should be a way to provide custom transport function which can be utilized in node.js envs to sepcifiy node-fetch or isomorphic-fetch or anything else
14:51:53 <krotscheck> (which to me seems like a transpiler thing, but it could be wrong)
14:52:29 <krotscheck> 8 minutes left
14:52:33 <krotscheck> More research?
14:52:39 <vkramskikh> yep, let's move on
14:52:40 <jprivard> indeed
14:52:54 <krotscheck> Alrighty.
14:53:10 <krotscheck> js-openstack-lib design: Configuring The Library
14:53:17 <krotscheck> #link https://review.openstack.org/#/c/331801/
14:54:03 <krotscheck> My recommendation is that we use os-client-config's clouds.yaml format. It's already a well established format, no need to reinvent the wheel.
14:54:31 <krotscheck> Actually, I don't think we have enough time to discuss this properly, so let's take that discussion to the review, and we'll bring it up again next week.
14:54:32 <vkramskikh> didn't read the spec completely, but at the first glance I don't think the library should be able to search files and try to parse yaml, just accepting config as a JS object
14:54:33 <azemlyanov> JS does not support yaml natively
14:54:51 <krotscheck> That is correct, it does not. js-yaml would be required.
14:55:55 <vkramskikh> I'll finish reading the spec and put my comments there
14:56:15 <krotscheck> Alright, let's skip to open discussion, we'll pick up at the first unrelolved topic next week and go from there.
14:56:19 <krotscheck> #topic Open Discussion
14:56:28 <azemlyanov> 3000 lines and 100kb
14:57:36 <krotscheck> azemlyanov: You mean js-yaml?
14:57:41 <azemlyanov> yep
14:58:22 <krotscheck> Understood.
14:58:26 <krotscheck> What other open discussion items do we have?
14:58:29 <cardeois> About test framework can we speak about it in this open discussion? or rather wait for next meeting?
14:58:36 <krotscheck> Here's good
14:58:51 <azemlyanov> test framework is a very big topic
14:58:57 <krotscheck> It really is.
14:59:07 * krotscheck is not expecting a resolution
14:59:27 <cardeois> azemlyanov but we could start at least. Like do we want to run the tests in-browser? or in node only? or both?
14:59:59 <krotscheck> cardeois: We test what we ship. Infra has harnesses for xfvb and browser launching.
15:00:03 <azemlyanov> you forgot phantomjs
15:00:08 <krotscheck> We don' thave selenium yet, but that's on my roadmap.
15:00:21 <krotscheck> Ok, we're out of time
15:00:26 <cardeois> ok
15:00:32 <vkramskikh> since we're targeting node and browsers, we need to test on node and browsers :)
15:00:38 <krotscheck> cardeois. azemlyanov: Get you rnotes on the etherpad and we'll pick it up next week.
15:00:45 <krotscheck> #endmeeting