Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Proposal: throw syntax error for `}` and `>` in JSX text.

See original GitHub issue

Feature Request

I would like to work on this feature!
- If needs be, I can look into it

Is your feature request related to a problem? Please describe.

The JSX spec [1][2] lists } and > as invalid JSX text characters.

JSXTextCharacter :

SourceCharacter but not one of {, <, > or }

However, babel does not throw a syntax error when it encounters a naked } or > in a JSXText string.

According to the spec, the only way you should be able to include either of these characters (similarly for { and <), is via a string expression: {'>'}.

Describe the solution you’d like I propose that babel should follow the JSX spec, and throw a syntax error if it encounters a “naked” } or > within jsx text.

From my experience, it’s uncommon that these characters are intentionally put in JSX text, and are instead the result of typos (i.e. typing {}, but having an editor auto-complete an extra } => {}}), or copy pasting errors.

Flow has already updated their parser to flag this as an error [3][4]. TypeScript is happy to make this change as well [5] (if Babel makes the change, as babel is generally considered the “reference implementation” for JSX). I have also raised an issue in acorn for the same functionality [6].

Describe alternatives you’ve considered

Custom lint rules
- We had these implemented at facebook before flow made it a parsing error. (The lint rules actually spurred the change).
- Outside of a tightly controlled monorepo, I can see that it would be hard to gain adoption for the rule, as not everyone uses linting tools, not everyone uses the react plugins, etc etc.
Prettier auto-formatting to convert } to {'}'}.
- This is an AST change, and prettier doesn’t like to change the AST when formatting.

Teachability, Documentation, Adoption, Migration Strategy If you can, explain how users will be able to use this and possibly write out a version the docs. Maybe a screenshot or design?

I think the best way to document this would be via clear and explicit error messaging. For example, the following code:

function F() {
  return <div>></div>;
}

function G() {
  return <div>{1}}</div>;
}

produces the following flow errors:

4:   return <div>></div>;
                 ^ Unexpected token `>`. Did you mean `{'>'}`?
8:   return <div>{1}}</div>;
                    ^ Unexpected token `}`. Did you mean `{'}'}`?

flow.org repl