[09:41:47] Good morning! [11:00:08] attamusc gibson042 nzakas1 ariya kborchers ... esprima meeting time [11:00:21] present [11:00:28] jqlog: esprimameeting is "attamusc gibson042 nzakas1 ariya kborchers ... esprima meeting time" [11:00:37] hrmph [11:00:48] gnarf: how do we get bot-t in here? [11:01:14] ok, just waiting for folks to trickle in, Bei, Ariya, Jeff [11:02:02] mikesherov: can you use esprimateam ? [11:02:11] sure [11:02:46] jsoverson: is ariya around? [11:02:49] and Bei? [11:02:59] @mikesherov i just pinged ariya, he timed out and is getting back on [11:03:11] hi ikarienator ! [11:03:20] Hi! [11:03:22] @ikarienator is bei [11:03:22] jsoverson: memorised “ikarienator”. [11:03:42] Sorry I'm late [11:03:54] b-ot: esprimateam is mikesherov ikarienator gibson042 ariya jeffmo [11:04:11] @esprimateam is mikesherov ikarienator gibson042 ariya jeffmo [11:04:12] mikesherov: memorised “esprimateam”. [11:04:22] * ariya is back [11:04:25] `esprimateam [11:04:25] mikesherov: mikesherov ikarienator gibson042 ariya jeffmo [11:04:29] hooray [11:04:35] shall we start [11:04:35] OK, seems like we're all here [11:04:42] howdy [11:04:55] nzakas1: is here for the first time, same with attamusc (my coworker Sean Dunn) [11:05:05] agenda: https://docs.google.com/document/d/1l02VT94tdphwUUZfPJorRYOY0Q_v41R_TyYhKayiP9M/edit# [11:05:09] do I show up as nzakas1 to everyone? I should just be nzakas :( [11:05:19] mikesherov: we don’t need to anything to take meeting notes? [11:05:34] mikesherov: I assume this channel is automatically recorded and stored as the note [11:05:45] @nzakas1 is nzakas [11:05:46] mikesherov: memorised “nzakas1”. [11:05:49] :-P [11:05:52] haha [11:06:14] stored, but I'll take meeting notes in the agenda as usual so I can send out a summary [11:06:48] http://irc.jquery.org/%23esprima-meeting/ [11:07:02] OK, lets start [11:07:31] by the way, send me your google email addresses so I can add you to edit the agenda [11:07:39] anyone can add items throughout the week [11:08:30] so, we have these irc channels with logging now, and I'll continue to serve as secretary for this meeting unless anyone objects [11:08:52] lbljeffmo@gmail.com [11:09:41] we are also off google code now [11:09:50] Thanks everyone for that effort! [11:09:58] woo! [11:10:00] the Issues tab is completely hidden [11:10:03] particularly ariya in the 11th hour :-) [11:10:13] there should not be any easy way to file an issue there anymore [11:10:19] also, we formed http://github.com/estree/estree [11:10:25] * ariya is luck Monday was a President’s Day [11:10:40] we should be attempting to resolve es6 questions there before implementing ourselves [11:11:07] of course, we can always decide to defer interop to next major release if we find that it's blocking, but in general, seems like interop is the best goal here [11:11:23] that said, seems that ikarienator’s class implementation might be at risk for 2.1 [11:11:30] I know ikarienator has been plugging following shift's lead in a lot of areas, which is great also [11:11:59] until https://github.com/estree/estree/issues/28 fully reaches the consensus [11:12:47] ok, so lets get concensus here first [11:13:28] I think 1 is no go, 2 is fine to say "method" as the kind instead of "", and for 3. "constructor" as the kind [11:13:31] but that's just me [11:13:41] agreed on all counts [11:13:57] jeffmo: risks for esprima-fb? [11:14:03] ariya ikarienator thoughts? [11:14:04] (reading that issue now…) [11:14:23] I am not strongly opposing or favoring one or another [11:14:34] ikarienator: how’s it done for shift ast? [11:14:44] Why is constructor a separate kind? [11:15:09] We have a MethodDefinition type which can be Getter Setter or Method [11:15:24] ikarienator: https://github.com/estree/estree/issues/28#issuecomment-74808152 [11:15:41] https://github.com/shapesecurity/shift-spec/blob/es6/spec.idl [11:15:45] all three seem fine to me. It might be a while before esprima-fb can be updated though…things are getting a little tight time-wise on my end for the next month or so [11:15:53] the idea being non trivial check in consumers of AST, and different semantics for `super` anyway [11:16:07] (or, at least a little time before *I* can update them…but doesn’t preclude someone else from going at it) [11:16:38] jeffmo: to be clear, we just want to make sure esprima-fb can eventually consume that change and not hurt downstream [11:16:48] mikesherov: yea I think that’s fine [11:17:11] OK, so ikarienator thoughts? I can also say #3 is a no go, which was my initial position [11:17:28] I agree [11:17:38] is a flag for constructor a choice? [11:17:49] I don’t have a strong opinion — but what’s the argument against? Just that it’s an unnecessary change? [11:17:50] probably too cumbersome, it will be false except in one case [11:18:02] The flag is only informative, it will be harmful when we have a transformed tree. [11:18:36] agree [11:18:45] Say if we have a non-static method whose name is 'constructor' and whose kind is not 'constructor', what does it mean? [11:19:02] right, so the idea is 1 of 4 things: 1. new node type 2. new property kind, 3. new flag on property for constructor, 4. nothing [11:19:04] +1 on it not being a flag [11:19:29] only 2 and 4 seem tenable to me [11:19:56] 3 would be back compat though [11:20:10] Shall we vote? [11:20:34] I'm for 4. [11:20:41] #2 still needs a thought on future friendliness [11:20:52] like nzakas1 said on when properties are being added there [11:21:08] yes, the body -> method is a no go [11:21:12] we all agree on that part [11:21:19] what is #4? [11:21:19] ohh, nvm, I see what you mean [11:21:23] ariya: properties don’t have to have the same kind enum as methods… [11:21:38] Class::body::body -> Class::body::methods we all agree, NO [11:21:45] I think having an empty string value that represents something is a code smell [11:21:47] No on #1 [11:21:50] Means for idea #3, do nothing special for constructors. [11:21:50] jeffmo: true, but that’s why I like Shift’s “elements” vs “body” [11:21:57] "" in MethodDefinition::kind -> "method" we all agree YES [11:22:14] schweet [11:22:25] * ariya agrees [11:22:28] I'm agnostic as to elements vs. body vs. magical things [11:22:35] just don't think methods is future-proof [11:22:37] agree [11:22:41] 3. constructor, there is question over whether or not we do nothing, or if we add new flag on property, or we add new value to kind [11:22:54] so let's vote on whcih path for 3 [11:23:02] ikarienator: says "do nothing" [11:23:18] I agree with that or adding a "constructor" value to "kind" [11:23:30] I vote for kind = “constructor” [11:23:37] nzakas1: said he was fine with new kind [11:23:42] yup [11:23:44] jeffmo seems fine with all [11:23:52] I’m fine with anything but #1 [11:23:59] that causes hassles for the tool that just cares about methods, whether constructor or not [11:23:59] right [11:24:03] no new type, that's crazy [11:24:04] I guess a small price to pay [11:24:16] so 4 for new kind, ikarienator for do nothing [11:24:27] ikarienator: are you ok with us recommending new "kind"? [11:24:52] does it complicate your PR or the code much? [11:24:54] Sure. If that's the result of the vote [11:25:06] Not at all. It will be minor change. [11:25:23] OK, so I'll put that forward to estree. [11:25:27] thanks everyone [11:25:36] *a minor change... I'm still learning English... [11:26:18] OK, so a bit off track, but next topic [11:26:24] espree [11:26:28] hold on a sec [11:26:34] what about “static”? [11:26:35] airya no problem [11:27:01] it’s a flag for current harmony and Shift [11:27:20] Oh... That should be in MethodDefinition right? [11:27:40] In Shift, we have a ClassMember which contains the static flag and a MethodDefinition. [11:27:45] ikarienator: in harmony branch it currently is a flag on methodDefinition [11:27:47] ariya: https://github.com/estree/estree/pull/19/files#diff-777fac1355306dc5dded0c710b37acdeR121 [11:27:59] it's now documented in estree too as a property [11:28:05] ah OK, so that’s already covered [11:28:08] I’m good now [11:28:09] go ahead [11:28:11] kk [11:28:18] on to espree... [11:28:24] had a good conversation with nzakas1 [11:28:45] we need to get a concrete path on steps forward [11:29:18] seems roadblocks include jsx support and language level flags (e.g. parse this as es5 vs. es6 vs. es7) [11:29:49] seems we are addressing most major concerns with current plans [11:30:21] nzakas1: the community keeps asking us about if we're going to merge, or combine efforts, etc. [11:30:28] nzakas1: what do you think about having espree be a downstream fork of upstream master (once feature parity makes it there) such that jsx support/flags/etc are unique to downstream, but it just tracks upstream? [11:30:40] this is what we do with esprima-fb — and so far it’s worked pretty well [11:30:54] honestly, my ideal situation is that Espree doesn't have to exist [11:31:17] it's just really three people who are working on it and I'd love to not have to keep it up-to-date [11:31:51] realistically, if we can get at least version-level flags into Esprima core [11:32:02] and esprima-fb tracks that [11:32:07] so, the question then becomes, if we add language level flags (which is an assumption at the moment), then is espree just esprima-fb? [11:32:10] right [11:32:14] then we can tell people to plug in esprima-fb if they want JSX support [11:32:41] yup [11:32:41] and there's some other minutia like globalReturn [11:32:49] but I think we can solve that trivially [11:33:11] yeah, that's one where if that method is exported, we can override it if that doesn't end up in Esprima [11:33:16] well ideally “Node.js script parser” can implemented of a stricter ES parser [11:33:25] you also need to strip the shebang [11:33:31] yes [11:33:33] Ok so in that world — where esprima-fb takes over — we’re probably blocked until esprima-fb can switch to tracking master instead of harmony right? Or are we talking addition of feature flags in both harmony and master? [11:34:18] well, not to defer that discussion, but I think if nzakas1 agrees to that, we can do that coordination outside of the meeting [11:34:32] nzakas1: has 3 guys who can help implement that today in harmony :-) [11:34:40] we just need to decide if we want that [11:34:43] mikesherov: ok, fair [11:34:58] and just a bit of background about the granular flags in Espree [11:35:11] mikesherov: I’m curious as to the complexity of feature flags — but admit I haven’t had a chance to see how it looks in practice with espree [11:35:22] there is an existing way to have ES5 and ES6 [11:35:30] complicated dance but it should work - > https://gist.github.com/ariya/0d465b26113981c4eef1 [11:35:41] they were added so we could continue doing minor releases for each feature we finished [11:36:03] Esprima 1.x also supports some nonstandard things for ES5 [11:36:11] like let and const and some SpiderMonkey extensions [11:36:15] Espree filters those out [11:36:28] SM extension? [11:36:42] also, with AST differences like .handler vs. handlers, we can't just swap in [11:36:49] right [11:36:57] well, esprima supports both right now [11:37:03] and won't break that till 3.0.0 [11:37:19] ah good to know [11:37:45] the other thing, and jeffmo and I talked about this a while back [11:37:50] is looking at ES7 and the future [11:37:53] so... [11:37:53] https://github.com/jquery/esprima/pull/234#issuecomment-74878772 [11:38:00] where features will be implemented in one-off manner [11:38:12] and https://github.com/jquery/esprima/pull/1039#discussion_r24720016 [11:38:31] nzakas1: I think some of these can be handled with a post-processing [11:38:33] right, es7 is... interesting [11:38:36] not ideal I know, but still [11:38:45] post processing is what I want to avoid [11:38:46] nzakas1: On ES7: That’s a good point. esprima-fb will want to move quickly with new ES features (even ones that havent’ been proposed yet). If esprima-fb becomes your base, maybe that’s the venue to implement thaem [11:38:57] ariya, seems like there are cases though in esprima where you want es5 mode vs. es6 mode [11:39:06] as per those two comments I just referenced [11:39:33] mikesherov: sure, that’s why this one works: https://gist.github.com/ariya/0d465b26113981c4eef1 [11:39:41] is the concern maintainance cost? [11:39:42] even easily extended to es7 [11:40:00] but those are separate codebases then you're saying? [11:40:33] yep [11:40:36] what is the downside of having them together? performance? maintainence cost? [11:40:39] One issue with labeling things on an es basis is that in the future it’s not going to be clear which features will necessarily make it into the next ES version until very close to when that version ships [11:40:50] It works well for currently shipping versions [11:41:05] +1 to jeffmo's comment, this is why Espree has more granular controls [11:41:06] but for future features<->version mappings, it could get a little hard to predict and classify [11:41:11] Having them together is hard to manage. Think about all the tests... [11:41:18] seems less then ideal as well to have to make fixes in 2 places... [11:41:20] mikesherov: maintenance cost, not that I’m adamant about it [11:41:31] ikarienator - it's not that bad [11:41:31] but then, if we keep discovering those cases [11:41:41] ikarienator: only because our test suite is less than optimal at the moment though [11:41:42] we do this for Espree pretty simply [11:41:54] I thik espree did a good job here showing the light for how testing can be laid out [11:41:57] Minor nit: I gotta say — having meetings in IRC is tough. Too easy to have multiple intertwined convos going [11:42:14] https://github.com/eslint/espree/tree/master/tests/fixtures/ecma-features [11:42:26] jeffmo and all, we can go back to Skype if you guys want. [11:42:41] mikesherov: sorry, lets talk about this later — didn’t mean to side track [11:42:44] np [11:43:13] right, so the concerns for single codebase are test difficulties and maintainence cost of flags [11:43:30] what is the issue with test difficulties? (just so I can understand?) [11:43:31] the concerns for split codebase is divergence (see harmony vs. master) [11:43:57] harmony is different, it’s started because the spec was still a moving target [11:44:00] ikarienator: is just saying you have to run a bunch more tests for the various flag combos [11:44:02] I don’t think the same case applies [11:44:09] mikesherov: got it [11:44:09] ariya, that's fair [11:44:44] so it seems that we want to decide whether to have language mode (es5 vs es6) in the same code base? [11:44:53] my point ariya though was even things like lookahead2 or createMarker [11:45:03] these improvements get made in one and not the other [11:45:22] imagine ikarienator having to implement better scan comments PR in both codebases [11:45:33] ariya, yeah [11:45:45] mikesherov: to be fair, those are not related to lang features [11:45:49] Well... That's true. [11:45:54] right, that's my point [11:46:00] Acorn already does this on a language-version basis already [11:46:15] if we decide better general strategy applies to es6, we have to redo the work in es5 codebase [11:46:15] all the way down to 3 [11:46:40] what about the tokenizer? nobody verifies that the tokenizer will not massively diverge for es5 vs es6 [11:47:01] right [11:47:08] It would be nice if harmony resumed tracking master once master is up to parity (I know I said kill harmony earlier today in an issue somewhere I think…but I take that back) [11:47:17] but then that's just more tests we must cover [11:47:18] mikesherov: I view Esprima 1.x as stable, there should not be any new features or perf improvements [11:47:27] general improvements happen in master and move downstream [11:47:30] ariya there are a bunch of bugs in 1.x [11:47:37] who is going to go back and fix those? [11:47:51] and who is going to fix the bugs we haven't found yet? [11:48:16] right, supporting 2 versions seems like more cost than having language level flags [11:48:32] mikesherov - any insights from jQuery maintaining two versions? [11:48:41] yeah, it's a pain in the ass [11:48:42] It’s certainly true that JS is and will be a moving target for the foreseeable future. It would be nice to have some sense of levels of stabilty in an upstream->downstream fashion. For example master -> harmony -> esprima-fb — and we can call esprima-fb the crazy wild west if everyone else wants :p [11:48:43] we still don’t have data points between the effort differences [11:48:51] we just give up if the cherry picks don't merge cleanly [11:48:55] amen to that [11:49:09] and for esprima, I imagine the divergence to be even greater, so chance for cherry-pick is reduced [11:49:09] jeffmo: I still propose to call esprima-fb as jsxparser [11:49:18] ariya: jsxandflowparser? [11:49:29] jsxandflowandnewesfeaturesparser? :) [11:49:36] jeffmo: but there is ocaml-based flow parser already [11:49:46] yes, this is true [11:50:04] ariya: yea, but esprima-fb is still the parser for the strip-out transformations for flow for the short-medium term [11:50:06] but this gets off topic. ariya has concerns over cost of maintainence of flags [11:50:14] yea sorry to side track [11:50:17] nzakas1: would you care to file those bugs? at least the one I’m not aware of [11:50:19] and there is some prior art here [11:50:28] then we can look at the effort differences [11:50:31] has anyone looked at how the Espree is doing it? [11:50:33] ariya: the fuzzer caught something like 40 [11:50:44] Yeah, I saw how espree does it [11:51:02] just throw inside the subparse functions if feature is off [11:51:14] mikesherov: the new fuzzer or the ones filed by mficarra already? [11:51:15] might be better for everyone to take a look at an actual implementation and then poke at it rather than theorizing if it will be bad [11:51:25] the ones from Michael already [11:51:43] nzakas1: that's what ariya is advocating for [11:51:46] collecting data [11:51:58] mikesherov: most are already fixed, unless he hasn’t reported new ones [11:51:58] ariya: is a very measured man, to his credit :-) [11:52:24] there is also https://github.com/jquery/esprima/issues/1053 [11:52:30] where the former is now allowed in ES6 [11:52:58] there is another good exercise [11:53:11] once we have a model of two-pass proposed by michaelficarra_ and ikarienator [11:53:19] https://github.com/jquery/esprima/pull/1039#discussion_r24720016 and this [11:53:23] the lang early errors can be implemented on top of that [11:53:39] just to summarize, group consensus is that language level *seems* like a good idea, ariya has concerns about implementation cost, we need to decide next steps so we can reach conclusion here [11:53:48] one last point from me [11:54:10] once we enumerate the full early error diff between es5 and es6, then we can make a good judgement [11:54:24] that said, we only know about that once most if not all es6 features are in [11:54:35] mikesherov: ariya: I’m pretty concerned about how new features will fit into the language-level flags [11:54:44] perhaps ikarienator or michaelficarra_ can chime in here, based on the shift exercises [11:54:44] yes [11:55:08] jeffmo: I share same concern [11:55:09] jeffmo: “new” as in es7 or later? [11:55:11] For example right now: we could say async/await is ES7 — but there’s no guarantee it will be ready for the ES7 train-schedul next year around this time. If not, it will be pushed to ES8 [11:55:20] right [11:55:23] If it gets pushed, do we move it under the es8 flag? [11:55:27] is that a breaking change? [11:55:33] I'm interested in solving incrementally though [11:55:49] (both possibly valid answers…just want to be sure we think it through) [11:55:57] right, tying esprima versions to language versions seems like a slippery slope [11:56:05] jquery found out this the hard way [11:56:23] which is why jquery 1.x and jquery 2.x became jquery 3.x and jquery-compat 3.x [11:56:46] that is why my suggestion was to put features under a language level only once more than one implementation agrees on the syntax+semantics [11:56:59] michaelficarra_: mmm hmm [11:57:14] * ariya updates https://gist.github.com/ariya/0d465b26113981c4eef1 to include es7 :-) [11:57:24] at that point, the implementations guide the committee, not the other way around [11:57:30] aroya, now we have 3 codebases to maintain? [11:57:39] ariya: * [11:57:50] idea: [11:57:53] What's the timeline for ES7 and esprima ES7 support? [11:57:57] mostly 2, esprima-fb being tracked on top of esprima 2.x [11:58:11] what if we have flags for spec’d language versions [11:58:20] and an ‘experimental’ flag for all yet-to-ship features [11:58:23] agree with michaelficarra - we were planning on doing this for Espree [11:58:24] so when async and await happens in es7, we release a new major version of esprima? [11:58:31] once all es6 was done, add an es6 flag [11:58:36] (or we can call it ‘pending-version’ instead of experimental maybe) [11:58:41] right, this is all fine [11:58:55] Then we can move out of pending-version and into ES7/8/9182 whenever it actually ships [11:58:56] but seems like we're planning next steps of an idea that doesn't have full support for the first step even [11:59:04] It somehow makes me think that a parser generator based two-phase parser is the way to go. [11:59:25] I agree [11:59:26] mikesherov: ok fair — what were the other concerns with language-version feature guards? Sorry I might’ve gotten tunnel vision there on accident [11:59:27] The validation part can be separated and reused for non-parsed trees. [11:59:28] ikarienator: but this assumes high cost for language level flags [11:59:33] which acorn has prior art for [11:59:33] let’s get back to data point collection phase [11:59:39] right [12:00:14] what do we need to collect to get support from you, ariya, as the holdout for language version flags? [12:00:29] or at least make a good decision here [12:00:43] even if it's nay on language flags [12:00:48] the code diff for es5 vs es6 [12:01:03] that mostly depends on finishing the remaining es6 features [12:01:19] I don’t want to us to keep discovering es5 vs es6 differences as we go [12:01:36] we have already discovered them [12:01:41] ariya: the goal of the code diff would be to example how we might have built in language-versioned flags? [12:01:45] i.e. the 2 differences already mentioned [12:01:47] jeffmo: bingo [12:01:55] mikesherov: only for stuff we’re working on [12:02:01] I think the difference is stated in the spec. [12:02:04] also, what about the tokenizer? [12:02:16] Annex E.1 [12:02:16] yes, tokenizer as well needs to be split [12:02:21] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-additions-and-changes-that-introduce-incompatibilities-with-prior-editions [12:03:15] tokenizer is hard [12:03:23] I think we ought to implement few more es6 features to get the feeling [12:03:24] we have a diff [12:03:31] OK, that's concrete [12:03:57] let's re-examine language flags after 2.1? [12:04:12] how about 2.2? [12:04:22] sure [12:04:26] post 2.1 I should have said [12:04:40] and if michaelficarra_ starts fuzzing the es6, the situation might be even more complicated [12:04:42] meaning we should have a decision by 2.2? or after 2.2 is released? [12:04:57] ariya: we will be fuzzing ES6 by the end of the week [12:05:05] (for Shift AST, that is) [12:05:05] ariya, also, perhaps examine acorn to help alay concerns? [12:05:06] after 2.2 is where I’m comfortable with [12:05:21] and maybe Espree? especially as it relates to testing [12:05:41] yeah [12:05:45] was going to say [12:05:55] I'm happy to answer any questions people might have [12:06:03] I already took a look at both [12:06:05] is team comfortable to revisiting after 2.2 [12:06:51] fine by me [12:07:00] OK, lets move on then for now [12:07:07] just for transparency: Espree is going to continue on its current path until this issue is resolved [12:07:29] makes sense [12:07:55] nzakas1: +1 I know lots of people are asking for this in JSCS and ESLint [12:08:06] nzakas1: if you find bugs in Esprima 1.x, let me know [12:08:41] OK, need to finsih this meeting, so lets try to get through next few items quickly [12:08:58] speaking of 1.x bugs: Suggesting 1.2.5 - to fix implicit octal (https://github.com/jquery/esprima/commit/7eb60150) [12:09:03] I'm +1 here [12:09:13] anyone not for releasing implicit octal fix [12:09:23] I think patch releases should be early and often [12:09:30] npm takes care of this :-) [12:09:44] before we go there [12:09:53] anyone against creating a release tracking issue [12:10:04] there is the usual thing of version number, changelog, publish etc [12:10:17] better to be explicit then forgotten [12:10:29] Ah, we should just document these steps in the wiki [12:10:37] I'd never argue against more documentation :) [12:11:01] mikesherov: let me create an example and see if we go for that or not [12:11:05] great [12:11:08] ariya: mikesherov : Isnt this tracked in the Changelog? [12:11:20] https://github.com/jquery/esprima/issues/1067 [12:11:26] or maybe you mean for upcoming releases? [12:11:42] Upcoming, yeah [12:11:46] got it [12:11:50] have an issue to actually do the release [12:11:57] +! [12:12:03] also plus one [12:12:14] ok, so sorry for rushing, just trying to move along on things that aren't controversial [12:12:28] yeah, we are overtime [12:12:33] we need to officially elect a team lead [12:12:41] I sent out email nominating ariya [12:12:51] mikesherov: your "implicit octal" is called a "noctal" [12:13:04] just need +1 from all team members [12:13:11] jeffmo: gibson042 ikarienator ? [12:13:20] or we can discuss [12:13:32] +1 for ariya [12:13:33] does ariya want to do it? :) [12:13:34] +1 for ariya [12:13:36] +1 ariya [12:13:40]