14:00:22 #startmeeting javascript 14:00:22 hmm, doesn't seem to work :( 14:00:22 Meeting started Wed Jul 6 14:00:22 2016 UTC and is due to finish in 60 minutes. The chair is vkramskikh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:27 The meeting name has been set to 'javascript' 14:00:28 oh it does 14:00:33 hi everyone 14:00:37 who's there? 14:00:41 hello there 14:00:55 #link https://etherpad.openstack.org/p/javascript-meeting-2016-07-06 14:00:57 Hello 14:01:00 hi! 14:01:03 here is the agenda for this meeting 14:01:12 hello 14:01:17 not so many things to discuss, so feel free to add your items 14:01:41 #topic ES2015 & Build approach 14:02:03 hello 14:02:14 I've created a spec for transpiler integration and build/testing approaches 14:02:18 #link https://review.openstack.org/#/c/332458/ 14:02:25 feel free to review 14:02:45 I've used modules/technologies that we agreed to use on the last meeting 14:02:52 o/ 14:02:55 yep sounds good 14:02:57 jasmine, karma, babel 14:03:11 however I did a checkout of this review 14:03:19 the only thing which we didn't discuss is the tool which builds browser version of the library 14:03:21 and npm install takes around 480MB 14:03:36 I mean node_modules, is that acceptable? and are you reproducing this? 14:04:02 the most popular modules for this are Browserify and Webpack 14:04:03 I've chosen Webpack since I have experience with it 14:04:03 As for the browser version I think webpack is the best choice right now 14:04:04 what's the builder? webpack? 14:04:43 I have experience with Browserify and if I'm not mistaking they say on their repo to use webpack now 14:04:48 browserify is much simpler tool 14:04:53 It's more modular 14:05:18 cardeois: what did you install to get 480MB of node_modules? 14:05:49 transpiler is heavy, it's dev deps, not prod deps 14:06:02 just checked Fuel's node_modules - it uses babel, webpack and lots of other stuff - it takes 175MB 14:06:34 vkramskikh sorry I'm wrong I did checkout this review https://review.openstack.org/#/c/334268/and did `npm install` 14:06:38 Babel is heavy, yes 14:06:38 but since 6.8 it takes less space 14:06:44 because before 6.8 it has dependency on Babel 5 to compile itself 14:07:16 cardeois: interesting, I'll check it 14:07:28 BTW, are you using NPM3? 14:07:40 But it uses babel 6.10 14:07:55 no but if I use npm3, it's smaller yes 14:08:08 NPM3 has dedupe functionality enabled by default, which results in much smaller node_modules 14:08:33 so, does anyone has any objections against using webpack? 14:08:40 yeah however is that a problem to force using npm3 or something? 14:08:43 I'll wait for 1 minute 14:08:49 nope webpack is good for me 14:08:50 no real competitors to webpack now 14:09:29 +1 for webpack 14:09:38 cardeois: don't think so, and AFAIR Ubuntu Xenial has NPM3 14:10:07 #agreed Use Webpack for creating browser version of js-openstack-lib 14:11:32 I'll try to create some PoC by the next week with karma/jasmine/webpack/babel 14:11:33 #topic Open Discussion 14:11:34 so, does anyone have any more topics to discuss? 14:11:57 what's the status of fetch? 14:12:17 it's ready for reviewing :) 14:12:38 But isn't it already done in this review https://review.openstack.org/#/c/334268/ ? (the PoC) 14:13:05 cardeois: I didn't review it yet, will take a look 14:13:30 yeah it contains webpack/jasmine/karma/babel all you want 14:14:26 awesome, maybe I'll take it over and resolve your comments since krot_vaca_jul19 is on vacation :) 14:14:34 ok 14:14:35 For open discussion, I have some questions, I could ask them in openstack-javascript but as everybody's there 14:14:51 I started with jprivard to understand how to setup a devstack gate 14:15:24 first item will be to add a functionnality (or integration) test in js-openstack-lib that our gate job will call, does that make sense? 14:16:08 I think yes 14:16:09 As no test setup is done yet should I depend on an existing review? (Sorry but I'm very new to all this opensource process) 14:16:48 cardeois: it seems the only option 14:16:58 ok cool 14:17:32 Also, a lot of python projects are using tempest to run the tests, We are using javascript though, so I guess we don't want to integrate with tempest? 14:18:44 I have no idea. we wanted to be a pure JS repo, though we already use sphinx for docs which is a python library 14:19:15 ok I'll try to find out by myself then, thanks anyway 14:20:08 I saw on the previous meeting there was a discussion about adopting Node6. Could anyone remind me why we need it? 14:20:34 to get rid of transpiler for node version of the library? 14:20:50 or just because it will have LTS status by October? 14:21:03 Maybe yes, but node6 even if it will be LTS is not LTS yet 14:21:40 And we need to support previous LTS node4. But yeahh the goal was to get all new functionnalities from node6 14:22:48 if it's about ES2016 features, it appears to be not really necessary as Babel covers most of the cases 14:23:23 except some rarely used features like Proxies - they're just not polyfillable 14:23:39 i have talked with krostcheck, he wanted the new features from node6, but we also need to support previous node4 14:23:41 ok 14:24:02 sorry for being late 14:24:51 msmol: we don't have many topics to discuss today, so it's time for open discussion 14:25:02 yeah so we can get a compromise: Use node6 features that babel can transpile 14:27:42 does anyone else have anything to discuss? if no, I'll close the meeting in 1 minute 14:28:40 nothing on my end 14:28:44 I have a last question for open discussion. We are starting to support cloud.yaml format (as JSON) so we can initiate communications with openstack. However, if we use our lib in server side and we want to keep the token, shouldn't we support a way to load our lib from a auth-token or something? My point being if a client has a server with sessions using our lib, how to we keep 14:28:44 the connection? 14:30:01 maybe it's a bad use of our lib I don't know, but in the apps at my job, we often store the catalog and token in session, so new request calls from browsers can reuse the token 14:30:46 I think lib and http server are different things 14:30:47 cardeois: you want to initialize the library using existing token instead of username/password? 14:31:11 I think both are ok 14:31:16 as an alternative yes 14:31:35 i think we should support it 14:32:04 yeah otherwise people using our lib in an http server will find our lib not that useful, or will hack it to find their way 14:32:19 That's what we did a long time ago with python-novaclient 14:32:30 our dummy sample keystone client already supports initialization with both token and username/password 14:32:38 https://review.openstack.org/#/c/332461/1/src/identity/index.js@37 14:32:41 oh alright, didn't see that 14:33:10 I think http servers are in python and nobody happy with node http servers 14:35:22 ok, if we still have anything to discuss, let's do it in #openstack-javascript 14:35:22 bye! 14:35:23 #endmeeting