[10:59:40] `esprimateam [11:00:20] `esprimateam is jeffmo ikarienator ariya nzakas1 nzakas mikesherov gibson042 [11:00:31] `esprimateam is `jeffmo ikarienator ariya nzakas1 nzakas mikesherov gibson042 [11:00:36] meh [11:00:57] no useful bot in the room [11:01:37] will wait 5 minutes for everyone to trickle in :-) [11:03:35] Hi guys! [11:03:42] ok, so I think we have a quorum now [11:03:56] ariya got pulled late into a meeting, so I'll run the meeting as usual [11:04:11] jeffmo, gibson042, nzakas1, ikarienator ready to go? [11:04:17] arthurvr: thanks for joining us [11:04:26] Interested in getting involved? [11:04:27] yup [11:04:29] ready [11:04:40] ready [11:05:06] good morning! [11:05:10] Introducing arthurvr, has helped the jQuery projects as part of the content team and has been doing a great job kicking ass there [11:05:11] greetings [11:05:19] looks like ariya made it after all! [11:05:24] Hey-hey [11:05:30] hi arthurvr [11:06:19] arthurvr: I'd love to hand over some documentation tasks for Esprima if interested? but we can discuss that later. Thanks for joining us [11:06:31] First items of business: since last week... [11:06:35] 1.2.5 released [11:06:38] hooray! [11:07:07] no reported regression so far, what a relief [11:07:11] :-) [11:07:36] Lots of activity in estree, landed the import side of modules, currently hammering out export side, which jeffmo can report on a bit later [11:07:50] yup, pretty cool [11:07:58] hopefully we can land so that 2.2 can have modules in it :-) [11:08:13] anyone else have anything significant to report as news since last week? [11:08:15] mikesherov: I’m interested in helping everywhere possible, but should say my focus is on other things currently. I’m following the project from a distance, just attending to hear where you’all are up to. [11:08:27] cool arthurvr thanks for the ears [11:08:30] unfortunately I was quite swamped with work in the last few days [11:08:38] yes, I'm afraid I was as well [11:08:53] only module-related stuffs from my end [11:08:57] it happens. Sometimes my job interferes with my work [11:08:58] arthurvr: esprima.org and other related documentation are the areas we could use help [11:09:11] whenever you're ready that is :-) [11:09:21] I got one minor task for lexical declaration and that should wrap it up [11:09:24] OK, so lets move on... [11:09:32] 2.1 progress [11:09:38] 1 error left for lexical declaration [11:09:50] Early errors for lexical declarations is hard to handle I think [11:09:59] should we delay 2.1 a few days until I got that sorted out? [11:10:28] well, we also decided on rest params in arrow functions as blocker to 2.1 [11:10:41] so that depends on answer from ikarienator as to progress there [11:10:43] ah I didn't got time to finish it [11:10:46] ikarienator: not all, let’s worry about const + initializer in for statement [11:11:14] ok, ikarienator, any estimate on when you might wrap that up by? [11:11:28] we could also get 2.1 out without that [11:11:42] I can probably do that tonight [11:11:54] BTW, for reference: https://github.com/jquery/esprima/milestones/2.1 [11:12:04] probably safe to move generator to 2.2 [11:12:11] yeah, I'm going to create milestone 2.2 and move stuff out [11:12:29] perfect :-) [11:12:42] ikarienator: arrow simplification moving to 2.2 as well? [11:12:53] yes [11:12:56] moved it already [11:13:01] Yes. [11:13:15] schweet [11:13:21] so if ikarienator can get rest arrow tonight, and ariya, you can get const + initializer done soon, let's call that 2.1 [11:13:39] LGTM [11:13:47] ariya, are teh other, more complex early errors for lexical docced somewhere so we know what's missing? [11:14:14] I think ikarienator is working on for shift parser [11:14:21] via that second-pass approach [11:14:33] we just need to take a look at it once ikarienator is done with it [11:14:34] ok, can someone document what we're missing though just for posterity? [11:15:00] ikarienator: ? [11:15:05] in an issue? [11:15:55] ok, I'll take that as a no? [11:16:08] probably can be extracted from https://github.com/shapesecurity/shift-parser-js/blob/es6/test/early-errors.js [11:16:14] two pass parsing? [11:16:19] not two pass parsing [11:16:24] the specific lexical early errors [11:16:27] I can do it, though I’d rather wait until ikarienator and friends are finished with the list [11:16:43] yes, even documenting that we *need* to do it in an issue is a start [11:16:59] fine if we wait, just want to capture the need to do it [11:16:59] I'm pretty sure I can get arrow rest tonight. [11:17:11] grep for let and const in that early-errors test suite :-) [11:17:16] right [11:17:27] so I'll create an issue [11:17:40] In fact, function/generator declarations as well [11:17:47] they are lexical in block scope. [11:17:55] kk [11:18:05] true, good point ikarienator [11:18:06] ok, so let's move on [11:18:27] ariya, can we say by Friday to get 2.1 wrapped up? [11:18:41] looks good [11:18:51] provided that there is no regression/showstopper [11:18:57] yes [11:19:21] OK, let's move on [11:19:43] https://github.com/estree/estree/pull/38 [11:19:43] https://github.com/estree/estree/pull/39 [11:19:46] hold on a sec [11:19:55] ikarienator: https://github.com/jquery/esprima/issues/1082 kinda blocking for me and many others [11:19:58] * mikesherov is holding [11:20:12] ikarienator: I can take a look if you rather prefer rest + arrow [11:20:28] I can take it. [11:20:34] Assign it to me. [11:20:55] for ref: https://github.com/jquery/esprima/blob/master/test/parselibs.js [11:21:05] and https://github.com/jquery/esprima/blob/master/tools/generate-test-fixture.js [11:21:06] is this just "create the file if it doesn't exist"? [11:21:15] correct [11:21:19] ok, cool [11:21:47] good, let’s move on [11:21:59] https://github.com/estree/estree/pull/39 https://github.com/estree/estree/pull/38 [11:22:05] jeffmo: you're up [11:22:07] export and import are looking better and better [11:22:20] this is just making sure we all agree with jeffmo direction here. [11:22:29] Ok, let’s see... [11:22:36] Which I do, but want to make sure we aren't talking past other team members :-) [11:23:09] ImportDeclaration ESTree spec text landed [11:23:17] \o/ [11:23:24] https://github.com/estree/estree/pull/35 and https://github.com/estree/estree/pull/39 [11:24:00] ExportDeclaration spec text chugging along and awaiting one last decision on a bikeshed from yours truly: https://github.com/estree/estree/pull/38 [11:24:48] The final bikeshed is just whether we should s/ExportBatchDeclaration/ExportStartDeclaration/ (seems more clear to me) [11:24:57] spec text doesn’t have a name for it (it just refers to it directly) [11:25:15] sorry — ExportStarDeclaration (not “start") [11:25:39] “star” is the notation, “batch” is the intention [11:25:48] I am edging towards batch [11:25:56] ExportStarDeclaration? [11:25:59] wondering if it should be ExportNamespaceDeclaration [11:26:13] to mirror ImportNamespaceDeclaration [11:26:15] Batch what? Windows script files? Batches of puppies? [11:26:21] * mikesherov shrugs [11:26:40] (it’s a nit — I think people will learn what it means no matter what we call it — but ExportStar just seemed more immediately clear to me) [11:26:47] I don't like that name "ExportStarDeclaration" :( [11:27:03] Yeah, I prefer Batch or even Namespace [11:27:08] Can we call it ExportAllFromDeclaration [11:27:13] Am I alone in thinking ExportBatch is a little unclear? Or are there better suggestions? Or does everyone agree that ExportBatch is pretty clear? [11:27:26] AllFrom is super clear [11:27:37] And we can have ExportFromDeclaration, ExportDeclaration and ExportDefaultDecalration [11:27:39] unfortunately the spec doesn’t call out a specific grammar for that [11:27:44] so, let's paint the bike red in the PR [11:27:57] ExportAllFromDeclaration reads a bit like a sentence (where “declaration” is the target) — but ExportAllDeclaration makes a lot of sense to me [11:28:02] * ariya doesn’t have a strong opinion on this [11:28:04] but aside from that naming, everything else seems legit to all? [11:28:27] ExportAllDeclaration +1 [11:28:28] I am fine with All or Batch [11:28:41] Star is too literal [11:28:49] I leave the decision to the native speakers :-) [11:28:51] Ok cool, I’ll follow up on the PR recommending “ExportAllDeclaration" [11:28:58] OK, cool [11:29:06] everyone else +1 on the rest of the contents? [11:29:08] And to pre-empt... [11:29:18] Are we ok with punting on this if others insist on ExportBatch? [11:29:28] yes, fine with Batch too [11:29:36] go for it [11:29:37] if so, would be nice to see +1's on the PR from ariya and ikarienator [11:29:38] sounds good [11:29:41] hi michaelficarra_ [11:29:55] only 30 minutes late this week! Getting better :-) [11:29:55] hello mikesherov [11:30:02] I’ll jump in once jeffmo adds the All part [11:30:03] :-P [11:30:04] oh no, I'm late again?! [11:30:07] What is ExportBatch? [11:30:13] ikarienator: confusing [11:30:14] :D [11:30:34] ikarienator: oh, you mean what did I mean when I said “insist on ExportBatch"? [11:30:41] michaelficarra_ is here, we’d better hurry [11:30:42] Currently the PR names it “ExportBatchDeclaration" [11:30:49] ikarienator: ^ [11:31:11] I mean, what does it represents? [11:31:21] ikarienator: export * from “SomeOtherModule" [11:31:24] Batch as a word is very similar to all [11:31:31] oh, lol [11:32:19] Ah, got it. I think ExportAllDeclaration is better. [11:32:24] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports-static-semantics-boundnames [11:32:31] “Return a new empty List” <— interesting [11:33:10] ok, moving along? [11:33:15] ah, I think I need to look at https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports-static-semantics-exportednames instead [11:33:28] next agenda item? [11:33:32] yeah [11:33:35] actually previous one [11:33:36] That is a particular complex part of the spec. Took us a long time to support it. [11:33:40] CLA [11:33:52] is everyone OK with switching to MIT? [11:34:25] doesn’t every contributor need to agree to that? [11:34:30] yes [11:34:42] * ariya is fine with any license [11:34:43] I assume it’s not retroactive, right? [11:34:46] Everyone needs to agree to CLA anyway* [11:34:59] what happens is we get CLA agreement from all contributors [11:35:01] MIT works for FB, so no problem on my end [11:35:03] and then switch [11:35:10] ok, cool [11:35:20] what's the difference between 2-clause BSD and MIT? [11:35:20] I'm curious about why [11:35:22] mikesherov: so it is retroactive? [11:35:35] unless anyone objects, I'm going to continue CLA verification with kborchers and proceed the easiest path [11:35:45] b [11:35:46] whether the easiest path is MIT or not remains to be seen [11:36:00] michaelficarra_: not much [11:36:05] don't mind me, just playing TPP [11:36:10] :-) [11:36:11] michael was doing twitch playing pokemon [11:36:17] talking about licenses, the one on the website is like 3 years outdated :) [11:36:25] mikesherov: if something other than MIT or BSD, please give me a heads up? [11:36:26] MIT is one of the free-est licenses, and the nuances between 2-clause BSD and MIT are over my head [11:36:37] jeffmo: will only be current or MIT [11:36:42] cool [11:37:01] and only change to facilitate not changing the wording of the existing jQuery CLA [11:37:24] kborchers: if you have a moment, can you async update us on the status of CLA verification? [11:37:29] sounds good, I’d say, let’s proceed [11:37:31] in the meantime, we'll move on [11:37:51] when we change to MIT, license will change and get updated [11:38:11] as long as it’s not WTFPL, I’m fine :-) [11:38:23] LOL [11:38:36] ES6 features main tracking ticket, I haven't gotten around to yet [11:38:40] just tied up like crazy [11:38:43] will this week [11:38:48] next up: versioning [11:39:08] so we got tied up in this conversation as far as feature flags go, but stepping back from that [11:39:17] I want to recommend a change [11:39:29] I thought we want to discuss that after 2.2? [11:39:37] feature flags we can discuss later [11:39:49] ah, this is language version? [11:39:51] wanted to discuss versioning of library for a moment [11:40:01] oh, you mean 2.1 vs 2.2 and such? [11:40:01] instead of continuing to support 1.x as "es5" and 2.x as "es6" [11:40:43] I'd recommend making a package "esprima-es5" that *removes* the bits of es6 that are in the 1.x line [11:40:55] and is really and truly an es5 parser [11:41:06] while continuing to develop esprima as an es6 parser [11:41:11] mikesherov: i have not done the grunt work to check every name in the list that was emailed against the spreadsheet ... if someone else wants to do that it would be great, otherwise i'll try to get to it asap [11:41:20] ok, thanks kborchers [11:41:36] 1.x only contains let and const in its es6-isms [11:41:42] and arrow [11:41:50] and that’s because it’s “sortof” supported by V8 and SM [11:41:55] arrow was never part of 1.x [11:41:58] ah [11:41:59] OK [11:42:12] the problem with having a single package with multiple versions doing different things is having them as deps in npm [11:42:29] for example, if I ever decided not to do language level flags in esprima [11:42:38] mikesherov: are you proposing this as short-term or long-term? [11:42:46] well, I dunno [11:42:51] the problem is one of practicality [11:43:01] if I want "es5" only mode in JSCS, how do I get that? [11:43:06] what I was playing with, and I can publish this for review, is a wrapper package [11:43:12] I can't depend on *both* esprima 1.x and esprima 2.x [11:43:19] “jsparser” that consumes esprima and provide that language flag [11:43:27] long-term, it'd be nice to have a single package with configurable behavior [11:43:28] plus flags for node-ism and browser-ism [11:43:32] I feel like this might inherently be tied to feature-flags, but how do we deal with breaking changes in ES6 that aren’t just additions (like valid identifier parsing, etc) [11:43:41] yes, I ideally would like one package with flags [11:43:58] jeffmo: second pass to rule them all :-) [11:44:02] the problems are well known, and we CAN have that discussion if we'd like [11:44:22] but today I just primarily want to layout the problem of effectively: jquery 1.x vs. jquery 2.x [11:44:34] and how we ended up with jquery 3 and jquery-compat 3 [11:44:36] and wrapper packages handle dumb downstream inclusion well [11:45:20] if someone wants to review it, I can make my jsparser idea public before next week meeting [11:45:38] ariya, I would only want that to be the esprima package [11:45:49] so that all current dependents have it [11:46:17] sure, that’s just deployment issue [11:46:22] correct [11:46:23] first we need to check if the idea is sound or not [11:46:27] right [11:46:33] it's certainly a stop gap [11:46:43] because then it either allows consumers to depend on both projects [11:46:53] for example, if you can try with JSCS, we have more data points to judge its existence [11:46:57] or rely on main esprima being able to defer to it's older parser [11:47:06] well, we do that already [11:47:21] we rely on esprima 1.x and a fork of the harmony branch to get es6 [11:47:41] and plan on keeping our 1.x dependency so we can error on es6 syntax in an es5 codebase [11:47:44] “jsparser” only depends on esprima 2.x, uses a second pass to remove es6-ism if es5 is requested [11:47:59] That would be my ideal ariya ^ [11:48:07] ok let me put that in my TODO [11:48:12] but you were main hold out there [11:48:27] like in my perfect world, esprima would use object methods for all parse functions [11:48:47] and if you request es5 mode, it replaces sub parse methods with es5 equivalents, including tokenizer [11:49:05] so you are essentially doing function compilation esque thing [11:49:16] and keep conditionals out of the actual parse sequence [11:49:23] that's my ideal behavior as well [11:49:54] sounds like an idea [11:50:14] but if we want to *eventually* get there, having an old version of esprima, repackaged as something else, included inside of esprima 2, is certainly an opaque stop gap [11:50:16] my gut feeling says that we need enumerate all early errors, both in es5 and es6, to be able to see the code diff [11:50:33] I want to solve for myself and nzakas1 [11:50:37] and also solve for es7 [11:50:53] otherwise we might end up with 10% shared code and 90% customized es5/es6/es7 [11:51:09] yes, maybe [11:51:25] so if we can get esprima 1.x repackaged, add flag to esprima2 to use old package, then we solve problem for now [11:51:39] I don’t want to get involved in the discussion too much since I only have use-cases (and believe in) using bleeding-edge JS — but I just want to remind everyone that the list: ES5, ES6, ES7 is about to grow a whole lot faster starting next year [11:51:41] and are one step closer to making me happy, and one step closer to getting espree unforked [11:51:58] yes, we have the advantage of time there though jeffmo [11:52:08] hopefulyl we'll have these questions answered by then [11:52:12] rather than starting from the implementation, what if we list all the requirements? [11:52:15] but I share same concern [11:52:19] perhaps start in a gist [11:52:26] that's why I asked about short-term vs. long-term, and as a short-term tactic I'm 100% behind the approach [11:52:29] we’re not talking about maintaining 2-3 variants of a parser…we’re talking about maintaining CurrYear-2013 variants of a parser going forward [11:52:57] Ok, again just throwing out the reminder that there’ll be a new version of ES every year, starting this year [11:53:04] yes [11:53:08] with you totally [11:53:21] incrementally, we need to arrive at that conclusion [11:53:33] though I assume es7 vs es6 will be less than es6 vs es5? [11:53:35] and repackaging esprima1.x as a dep of esprima 2.x is "good enough" for now [11:53:43] ariya: hopefully so :) [11:53:59] aroya, yes, and that's when the code reuse argument though swings in flags rather than package's favor [11:54:14] ariya: I only think it’s interesting to point out because it means more permutations of a second-passer (or more permutations of parsers, etc) [11:54:21] es7 will be almost like es6, with 90% shared, 10% diff... hopefully [11:54:48] this is all theoretics [11:54:55] from a concrete perspective [11:55:12] the problem I have today is having 1 package to rely on for parsing either es5 or es6 [11:55:21] and we can solve that *cheaply* [11:55:43] are you going to give my jsparser idea a chance or not? [11:55:52] yes, that's what I want :-) [11:56:02] that's the "cheap" answer! [11:56:17] cheap in a good way [11:56:26] affordable, that is [11:56:51] BTW, I need to run to a lunch appt [11:56:57] * ariya only has a few mins left [11:57:03] ok, so let's settle on jsparser idea [11:57:07] *for now* [11:57:13] make me and nzakas1 happy [11:57:35] I also still need to look at nzakas1 external comment attacher [11:57:40] probably after we got this 2.1 out [11:58:00] yes, that's next agenda item [11:58:12] nzakas1: you're up re: SLA and comment attachment [11:58:45] I'll speak for him until he gets here? [11:59:20] Basically, can we decide that we at least respond, even if it's "hey I'm busy and will review soon", to ever issue soon after it's reported? [11:59:37] sorry, hellfire and brimstone over here [11:59:41] NP [11:59:54] nzakas1: submitted comment attachment issue with details with got no response from rest of team for days [12:00:01] which is not as bad because it's him and he knows us [12:00:16] but we need to ensure doesn't happen for other contributors [12:00:20] yeah, the fastest way to discourage contributions is to ignore them [12:00:28] even if a response is just "hey, I'll take a look next week" [12:00:35] that goes a long way towards building trust [12:00:46] yeah, so I can gaurantee I'll do that going forward for [12:01:04] but can we agree on some SLA for getting that type of comment on an issue/PR? [12:01:13] in ESLint we have a 48 hour SLA [12:01:17] I can commit to 48 hours [12:01:38] Hey all, I have to run — anything else you need from me before I bail? [12:01:56] jeffmo: +1 on 48 hour SLA? [12:02:14] gibson042: ikarienator ariya objections to concept of SLA? [12:02:24] I like that [12:02:40] mikesherov: +1 in theory, but could be hard in practice given that we all have other things demanding attention it seems [12:02:56] jeffmo: literally just "hey, we'll look soon" [12:03:02] I'll ensure that [12:03:09] gibson042: can you help ensure that too? [12:03:11] oh ok, well consider me +1 [12:03:17] +1 [12:03:20] OK great [12:03:30] I'll document it in wiki as part of maintainers guide [12:03:38] gibson042: and I will ensrue ti happens [12:03:54] bye jeffmo! [12:04:04] ariya: as far as specifics go, can you look at nzakas1's proposal for comment attachment this week? [12:04:07] ttyl all! [12:04:08] after 2.1 is done? [12:04:14] yeah, that’s my plan [12:04:19] Beautfiul [12:04:47] if we can get that done, and we can move forward with jsparser idea, we've removed almost all blockers to espree as true downstream [12:05:03] OK, got to run now [12:05:07] OK, yeah, me too [12:05:11] thanks everyone! [12:05:14] thanks folks! [12:05:15] ttfn [12:06:57] Bye everyone!