14:00:33 #startmeeting javascript 14:00:39 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 Good morning everyone! 14:00:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:43 The meeting name has been set to 'javascript' 14:00:51 o/ 14:00:56 Agenda: 14:00:58 o/ 14:00:58 #link https://etherpad.openstack.org/p/javascript-meeting-2016-06-22 14:01:16 o/ 14:01:24 hello! 14:01:46 #topic Core elections! 14:01:48 hi! 14:02:13 hello all 14:02:19 betherly, SotK, Zara, timothyb89, jaranovich, msmol : Hi everyone! 14:02:23 hi 14:02:25 hi! 14:02:28 hello! 14:02:30 hi krotscheck! 14:02:44 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 I've gone through and picked all the people who have, to date, performed code reviews on those project. 14:03:15 And I nominate all of them! 14:03:26 With two caveats: 14:03:39 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 (or, if you're not here, I'll reach out to you later) 14:04:22 2- We agree on a reasonable baseline for the # of reviews. 14:06:01 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 Zara: That's fair. 14:06:19 Does anyone disagree with me setting the bottom bar for reviews at > 2? 14:06:20 same for me, I'm brand new in this :) 14:06:28 fine by me 14:06:43 I'm happy to +1 stuff. if later on there's a core-shortage, maybe we can talk xD 14:06:50 but yeah, not a good idea for anyone yet. 14:07:19 for what it's worth, that all sounds good to me 14:07:22 sounds good to me 14:07:30 i'm fine with it 14:07:37 Alrightey, so that sets the nominee list for js-openstack-lib to vkramskikh. 14:07:43 vkramskikh: Would you like to be core? 14:07:59 krotscheck: yes I would, I'm really interested in the project 14:08:04 all: does anyone disagree? 14:08:10 * krotscheck waits 30 seconds 14:08:58 Alrightey, core #1 is vkramskikh! 14:09:03 \o/ 14:09:06 woohoo 14:09:08 +1 14:09:15 congrats, vkramskikh! 14:09:22 yay! 14:09:26 Next: js-generator-openstack 14:09:26 congrats! 14:09:56 The current nominee list are yujunz (not present, late in shanghai), betherly, and notmars. 14:10:06 (notmars is bruno). 14:10:24 betherly: Would you like to be core? 14:10:29 he's not present too early for him 14:10:37 cardeois: What's his timezone? 14:10:43 congrats vkramskikh :) 14:10:43 (for notmars) 14:11:06 im happy to be 14:11:07 EST but he's not a morning guy 14:11:13 cardeois: I can relate. 14:11:27 Alright, does anyone have disagreements with betherly as a core for generator-openstack? 14:11:42 I'm all for it 14:12:21 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 ALrightey! 14:13:15 congrats betherly! 14:13:19 * krotscheck will ping the others 14:13:19 yaaaaaaay! congratulations, betherly! 14:13:24 thanks :) 14:13:25 congrats betherly :) 14:13:29 #action krotscheck Add vkramskikh as core to js-openstack-lib 14:13:35 (and hopefully congratulations yujunz and notmars, will see!) 14:13:37 congrats :) 14:13:38 #action krotscheck add betherly as core to js-generator-openstack 14:13:55 congrats betherly! 14:13:56 #action reach out to notmars and yujunz for their consent as project cores on js-generator-openstack 14:14:11 Who would like to be responsible for updating the meeting chairs on eavesdrop? 14:14:28 #action krotscheck reach out to notmars and yujunz for their consent as project cores on js-generator-openstack 14:15:00 If nobody volunteers, I'm going to nominate vkramskikh to do that :D 14:15:16 ok, just please explain how to do that :) 14:15:38 vkramskikh: Submnit a patch to the openstack-meetings repository that updates the javascript-sdk meeting chairs 14:16:03 #action vkramskikh Update javascript meeting chairs in openstack-meetings 14:16:16 #topic js-openstack-lib design: Isomorphism 14:16:53 "Isomorphic" in this case means a library that works both in the browser and in a node.js runtime. 14:17:11 I think it was already discussed in #openstack-javascript and everybody agreed that it should be isomorphic :) 14:17:15 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 Yes I think it's a must have 14:17:39 At this time, I've only heard demand for browser clients though. 14:17:46 I also don't have much experience, but don't see any obstacles 14:17:49 any pure JS lib is isomorphic 14:18:11 azemlyanov: Are you volunteering to build our HTTP request abstraction? ;D 14:18:25 fetch API? 14:18:44 azemlyanov: http://caniuse.com/#search=fetch 14:18:55 53% support in browsers. 14:19:00 One more note though: 14:19:11 I heard vkramskikh had desire to do it 14:19:12 We only support what we can test, and IE/Safari are not open source. 14:19:16 So we cannot support them. 14:19:23 jQuery for http? 14:19:37 yes I do, I'll express my thoughts on it when time comes (we have this item in agenda) 14:19:40 In other words, the fetch api is available and supported on all the browsers we can test. 14:19:44 fetch API is modern, plofill for obsolete browsers 14:19:47 Well I think there is fetchAPI implementations in npm 14:19:57 to support browser not supporting them 14:20:23 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 or what azemlyanov said 14:20:32 DOes anyone disagree? 14:20:45 (Does anyone disagree with openstack-lib's need to be isomorphic?) 14:21:18 #agreed js-openstack-lib should be isomorphic. 14:21:39 #topic js-openstack-lib design: ES5 or ES6 (ES2015) 14:21:52 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 Babel anyway. 14:22:06 +1 14:22:11 ES5 is pretty old, no classes, no iterators, destructuring 14:22:17 I agree with vkramskikh. Was just typing that I think ES6 should be the direction we go in 14:22:49 sets the right precedence moving forwards as well 14:23:04 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 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 cardeois: Whoa, 400MB? That's ridiculous! 14:23:45 ugh :/ 14:23:52 hey, folks 14:24:00 tsufiev: Hi there! 14:24:04 modern Babels 6.8+ are quite "slim" (about 50mb) 14:24:06 yeah it is, I discovered that with babel using ES2015, but maybe there's a better way 14:24:16 This might be related: 14:24:16 #link https://blog.nodeswat.com/what-i-learned-from-analysing-1-65m-versions-of-node-js-modules-in-npm-a0299a614318 14:24:19 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 oh cool vkramskikh will try that 14:24:53 tsufiev: Good catch, thanks! Fixed. 14:25:12 It doesn't sound like anyone disagrees with ES6 as the base language. 14:25:24 Can't we just supply the ES6 version and let people transpile it themselves in their projects should they choose? 14:25:26 It also sounds like generator-openstack is stuck in ES5 land for the time being. 14:25:54 es5 is subset of es6 14:26:00 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 Well vkramskikh was saying we can't upload ES6 to NPM is that true? 14:26:13 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 And I don't know if requirejs supports that... 14:26:33 npm does't care 14:26:43 Does requirejs care? 14:27:07 Sounds like we need some research. 14:27:08 requirejs can parse es6 code, but it's really painful to setup all that properly 14:27:20 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 Yeah maybe to avoid complex setup for people using the lib I think it's better to provide the transpiled version 14:27:23 with babel plugin which is not officially supporte 14:27:24 d 14:27:25 requirejs is going away nowadays 14:27:30 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 (instead of / in addition to) 14:28:24 ok then we could eventually provide both if we can 14:28:24 for example d3 is es6 and also npm published: https://github.com/d3/d3-format/blob/master/package.json 14:28:58 I had no problems with es6 and es5 is a single npm package 14:29:26 azemlyanov: That's encouraging. 14:29:34 We can set the engine flag in the package as well, right? 14:29:47 How much of ES6 is supported by Node4 LTS? 14:29:55 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 https://kangax.github.io/compat-table/es6/ about a half 14:30:24 #link https://kangax.github.io/compat-table/es6/ 14:30:35 Well, looks like we'd have to transpile anyway until we shift to Node6 LTS 14:30:50 50% for node4 vs 93% for node6 14:31:01 quite poor support. node v6 is some >95% 14:31:26 SO, it sounds like we're trying to get to as much of ES6 as possible 14:31:44 agreed 14:31:48 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 Meaning we'd have to polyfill/shim/transpile anyway 14:32:39 so then how will we test the non-transpiled version? 14:32:54 msmol: Good question. 14:33:02 probably we won't 14:33:08 We could teach infra how to do nodeenv. 14:34:05 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 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 cardeois: True, but then our coverage metrics are going to be meaningless. 14:34:45 krotscheck: why? 14:35:13 vkramskikh: We'd have to run instanbul's code annotation first, then pipe it through the transpiler. 14:35:38 I'm not confident that the transpiler won't munge and destroy the code annotations. 14:36:17 research is also needed here, but I believe there is a solution for this 14:36:25 both babel and istanbul are quite popular 14:36:48 vkramskikh: agreed 14:36:50 Btw what test framework do we want to use? (or should we have a different topic about it?) 14:37:17 cardeois: Probably a different topic. 14:37:35 Ok, so we need more research. We already have a spec up for review here: https://review.openstack.org/#/c/332458/ 14:37:38 #link https://review.openstack.org/#/c/332458/ 14:37:59 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 yes I would 14:38:29 #link https://onsen.io/blog/mocha-chaijs-unit-test-coverage-es6/ 14:38:41 seems like it's possible 14:38:43 vkramskikh: excellent. I'll be able to provide any necessary support vis-a-vis infra. 14:39:40 #action vkramskikh Research ES6 transpiling options with regards to Node4, Node6, npm publishing, and update spec. 14:39:56 Overall I think we're agreed that we want as much ES6 as possible. 14:40:02 #agreed As much ES6 as possible. 14:40:17 I'd like to move on, any other comments on this topic? 14:40:39 none on my side 14:40:53 #topic js-openstack-lib design: What is server interaction approach? 14:40:58 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 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 fetch polyfills are available everywhere 14:42:30 Can the polyfill be handled in the transpiler? 14:43:13 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 https://review.openstack.org/#/c/331772/ here's how we switched to fetch in fuel 14:44:05 https://review.openstack.org/#/c/331772/1/webpack.config.js that's what was necessary to add polyfill to the project 14:44:16 vkramskikh: It's not browsers I'm concerned about. It's browsers vs. node. 14:44:39 there's also superagent which is a quite popular project supporting both browser + node 14:45:04 nothing different here - transpliers are usually configured not to mangle non-project code 14:45:24 vkramskikh: THe example you gave me a few days ago had the line "require('node-fetch')" in it. 14:45:30 Is that not necessary? 14:46:00 yes it is, but I still don't understand what it has to do with transpilers :) 14:46:26 vkramskikh: Well, first of all, you're making the assumption that we're using webpack. 14:46:34 superagent seems to be quite popular, worth researching 14:46:35 That hasn't really been decided yet. 14:47:04 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 Hi there, larainema! 14:47:23 yes, but that's yet another thing that has nothing to do either with transpilers and polyfills :) 14:47:37 they are quite independent 14:47:49 vkramskikh: We can't get the transpiler to automatically add node-fetch so we don't have to require() it? 14:47:50 I think I could explain in more thoroughly in the spec 14:47:53 orthogonal ;-) 14:47:56 That's probably a good idea. 14:48:13 I guess the real question I'm asking is: What runtime will our original source code target. 14:48:17 isomorphic-fetch: https://github.com/matthew-andrews/isomorphic-fetch just found on google, no idea of it's quality 14:50:01 krotscheck: what do you mean runtime? 14:50:37 cardeois: It's with regards to node-fetch style modules. If the library's isomorphic, we can't use those. 14:50:59 We could use the one msmol just found, or adapt our own. 14:51:20 Yeah I guess we could do some research about it 14:51:29 it's rather build process to determine runtime and external deps 14:51:36 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 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 (which to me seems like a transpiler thing, but it could be wrong) 14:52:29 8 minutes left 14:52:33 More research? 14:52:39 yep, let's move on 14:52:40 indeed 14:52:54 Alrighty. 14:53:10 js-openstack-lib design: Configuring The Library 14:53:17 #link https://review.openstack.org/#/c/331801/ 14:54:03 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 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 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 JS does not support yaml natively 14:54:51 That is correct, it does not. js-yaml would be required. 14:55:55 I'll finish reading the spec and put my comments there 14:56:15 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 #topic Open Discussion 14:56:28 3000 lines and 100kb 14:57:36 azemlyanov: You mean js-yaml? 14:57:41 yep 14:58:22 Understood. 14:58:26 What other open discussion items do we have? 14:58:29 About test framework can we speak about it in this open discussion? or rather wait for next meeting? 14:58:36 Here's good 14:58:51 test framework is a very big topic 14:58:57 It really is. 14:59:07 * krotscheck is not expecting a resolution 14:59:27 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 cardeois: We test what we ship. Infra has harnesses for xfvb and browser launching. 15:00:03 you forgot phantomjs 15:00:08 We don' thave selenium yet, but that's on my roadmap. 15:00:21 Ok, we're out of time 15:00:26 ok 15:00:32 since we're targeting node and browsers, we need to test on node and browsers :) 15:00:38 cardeois. azemlyanov: Get you rnotes on the etherpad and we'll pick it up next week. 15:00:45 #endmeeting