Include JSX Extension

[sebmarkbage]

I thought I'd open the discussion around move the JSX extension to the ESTree repo. It could go into an experimental extensions section since it is not part of the spec nor any active proposal. However, it is fairly stable and implemented by several downstream parsers.

Currently this extension lives in the JSX spec repo:

https://github.com/facebook/jsx/blob/master/AST.md

It would be convenient for tooling implementors to have a single place to look at.

[sebmck]

I'm not opposed to this. Another thing that this brings up is how to handle copyright and licensing in ESTree.

[RReverser]

I think it would be still the best to keep extension specs in separate repos under corresponding owners, otherwise we might end with maintaining a lot of JS dialects in one centralized repo instead of "modular" approach that separate dedicated repos give.

[nzakas]

In my opinion, once an extension becomes ubiquitous, it would be nice to have in this repo (like the appendices in ECMA-262).

[RReverser]

once an extension becomes ubiquitous

Do you think we should include type annotations then? Which version if so (TypeScript? Flow? ...?)

[nzakas]

I don't, because everyone is doing it differently right now.

For JSX, any parser that implements it is implementing the same form, so it's already a pseudo-standard.

[RReverser]

For JSX, any parser that implements it is implementing the same form, so it's already a pseudo-standard.

I never argued that it's a standard, as well as TypeScript has own one, and as of now both of them live in own curated specs, so I'm just proposing to leave things that way.

Personally, I also contributed to JSX spec and 100% interested in it's support and further evolution, just saying that ESTree itself should cover official ECMAScript only IMO.

[nzakas]

::shrugs:: From a parser implementer point of view, I'd prefer having things in one spot. I also don't feel super strongly about, so I'd defer to consensus.

[sebmck]

@RReverser

I think it would be still the best to keep extension specs in separate repos under corresponding owners, otherwise we might end with maintaining a lot of JS dialects in one centralized repo instead of "modular" approach that separate dedicated repos give.

Not sure if this is what you're directly proposing but what about having a estree/jsx repo?

[mikesherov]

I agree with @sebmck that it opens ESTree to licensing copyright questions... which isn't so bad, but needs answering.

[mikesherov]

I'm also fine with having the JSX extension living here. Seems as if we can evaluate individual extensions with

[dead-claudia]

I do agree with @sebmck's idea of having it in a separate repo, where issues with nonstandard extension specs can be separately monitored. I would like to also mention that either TypeScript or Flow's type annotation format appears to me to potentially become future valid JavaScript (although not in the ES7 or 8 road maps).

[sebmck]

Can we have a consensus on this? I'm 👍 on having it in a separate repo.

[mikesherov]

I'd prefer like @nzakas to have it here, so I still want to look into licensing for a bit before we come to an answer.

[sebmck]

@mikesherov In the core repo or in a separate one? I only suggest a separate repo because if JSX is included then I'd like to write one up for flow too (of the current esprima-fb structure and with @jeffmo's blessing of course) and it's arguably the slippery slope bought up by @RReverser .

[mikesherov]

I was thinking more along the lines of a directory here marked extensions or some much. I don't care much either way, so if you guys feel strongly about separate repo same org, let's do it :-)

[jeffmo]

I would kind of prefer separate-dir/same-repo just to help things stay in sync with official lang updates.

[RReverser]

@jeffmo What makes it "not in sync" when in separate repo?

My preference is still to keep vendor-specific extensions under their vendors. As a user (developer), I'd rather expect to find JSX AST spec right near the JSX syntax spec in facebook/jsx than under estree/estree/blob/master/extensions/jsx.

If others don't consider this as an option, then let's at least define extensions in a separate repo - that would allow to keep clear scope and commit history of this repo as ECMAScript-only.

[sebmck]

@RReverser Extension specs may be tightly coupled to the core spec and it's weird/hard to juggle between different repos.

[jeffmo]

@RReverser: Nothing, it's just harder to notice disjointness when the two things don't sit together. Syntax extensions are always coupled with the spec they're extending. It's doable...it'll just require more logistics to keep things up to date, etc. I'm basically just asking that we make it easier to keep the two specs in linear synchronization.

Another future option I have in mind here is that we can consider moving the ESTree spec to be built in an ast-types format in the future (@benjamn has talked about this a bit, and it's a pretty neat idea). This allows the spec to be machine readable. At that point, it's possible to write scripts to validate definitions, AST structures are well-formed and consistent, etc. If we were go to this route, it would also be possible to split JSX off in to another repo and simply write it's machine-readable specs as dependent on a particular version of ESTree...but now you have intra-spec versions to deal with when you make decisions on how to reference the JSX spec. The logistics at this point basically dovetail into similar conversations about having parsers that allow syntactic plugins. Its possible (conceptually), but logistically it's going to be tricky when changes occur.

[RReverser]

@sebmck

1. It's not harder/easier/different than juggling between files in the same repo. In any case you open both specs in separate browser tabs while working.
2. JSX is not an example of "tight coupling" IMO, it perfectly integrates into any of ES5/ES6.
3. Extensions that are tightly coupled to spec may choose to fork this repo, and to maintain it just like parser forks are (it will be even easier, as spec changes not as frequently as parser code).

[sebmck]

@RReverser That seems crazy unnecessary. How many ESTree/SpiderMonkey extensions can you think of that would justify such fragmentation?

[RReverser]

@sebmck I don't - that's why I didn't understand your "tight coupling" argument and added #3 just in case as a solution for "even if there are such extensions ...".

[sebmck]

@RReverser There's the potential for tight coupling. For example, I want to write a Flow AST spec, it's tightly coupled to the way function parameters, classes etc work and future nodes will likely need to be extended.

[RReverser]

@sebmck I don't see how are they coupled here, as you will be most likely extending base interfaces like Pattern and others instead of each possible production, but even if they're, see argument #1 and tell what the difference it makes.