XJS -> JSX

[fkling]

Depends on benjamn/ast-types#93. I did a simple search/replace here as well and ran npm test with the updated ast-types version.

[fkling]

esprima-fb has to be bumped too (tests still pass).

[benjamn]

For backwards compatibility, can we keep the old case labels for now?

case "XJSElement":
case "JSXElement":
    var openingLines = path.call(print, "openingElement");
    ...

[fkling]

Yeah, I wanted to ask you about that and forgot... will update.

[fkling]

Although, is this actually necessary if ast-types cannot produce XJS* nodes anymore? Anyways, I updated it.

[benjamn]

Yeah, older versions of esprima-fb can still produce XJS* nodes, so I think we should be able to print them.

[fkling]

Maybe I'm missing something, but wouldn't recast not be able to handle "older" ASTs because the new version of ast-types doesn't support XJS* nodes either? Or are you planning to merge this change independently of the ast-types version?

Or do some parts of recast work without ast-types and directly on the AST?

[benjamn]

Do you know if parentheses are still needed around multi-line JSX return arguments?

[fkling]

You mean for

return (
    <div>
    // ...
   </div>
);

?

I would believe so. If there is a line break after the return, ASI will kick in. A JSX -> JS transpiler (or even recast?) might be able to detect that and move the opening tag on the same line, but that seems more magical.

[jenseng]

parens shouldn't be needed, since tag balancing trumps ASI... for example, jsx cli (react-tools) converts this:

return <div>
  there are
  <b>multiple</b> lines
  here
</div>;

into this:

return React.createElement("div", null,
  "there are",
  React.createElement("b", null, "multiple"), " lines" + ' ' +
  "here"
);

[fkling]

Have parens be ever needed for

return <div>
  there are
  <b>multiple</b> lines
  here
</div>;

?