ES4? I hope you meant ES5.

Yikes, yes.

ECMAScript 6 is a superset of ECMAScript 5, which is a superset of ECMAScript 3. I see only two options: ES6 and JSX.

@nzakas thank you for reconsidering this!

Another library which can provide traversal over es5/es6/jsx/es7 is ast-types which is used by recast.

Please note that we're committed to JSX and in order to make sure that the integration with tooling such as eslint is as easy as possible we created a specification for JSX.

• JSX Specification: http://facebook.github.io/jsx/
• JSX AST Specification: https://github.com/facebook/jsx/blob/master/AST.md

@vjeux good to know! The spec is useful, but not as useful as libraries that we can plug in and have "just work". :) Have you (all) done any work around creating an escope that's compatible with JSX?

@nzakas: It's worth noting that esprima-fb is the esprima harmony branch + JSX (it tracks the upstream harmony branch, we periodically merge in updates from upstream, and we always send harmony-specific PRs to upstream first) -- so if you just always use esprima-fb for ES6, you're supporting both ES6 and JSX. If you were to provide a toggle between esprima-fb and esprima/harmony, the only distinction you'd see (barring bugs) is that esprima/harmony would give a parse error if you threw JSX at it.

On the other hand, you still have the option of rejecting JSX in code if you so desire -- even if the parser parses it (if you see the presence of a JSX node while traversing the syntax tree, you error).

Would it make sense to simply provide a no-JSX lint than a toggle on which parser to use?

The only issue using esprima-fb (or the esprima harmony branch) applied on ES5 JS code is the following:

lib/rules/no-extra-parens.js
  43:12  error  Expected a "break" statement before "case"  no-fallthrough
  53:12  error  Expected a "break" statement before "case"  no-fallthrough

The harmony branch has the fallthrough comment at a different position in the AST. Shouldn't be hard to get the lint rule accept both positions.

In order to lint ES6 or JSX code, there are a few rules that need to be updated. For example the unused variable rule doesn't consider to be a 'use' and marks it as unused.

We're currently playing around switching from jslint after pre-processing to eslint. So far we've got something "working" by disabling a few rules. It doesn't seem that it would require drastic changes and only a handful of pull requests would be needed to support it properly.

In order to lint ES6 or JSX code, there are a few rules that need to be updated. For example the unused variable rule doesn't consider to be a 'use' and marks it as unused.

This is tricky because in React's JSX, writing <Button> counts as a use of the variable Button but since JSX itself doesn't specify semantics, that might not be true with a different transformer.

The harmony branch has the fallthrough comment at a different position in the AST

This sounds like a bug we should just get fixed -- not quite sure why they differ

For example the unused variable rule doesn't consider to be a 'use' and marks it as unused.

This would be a React-specific lint rule. JSX is just syntax -- React applies meaning to that syntax; So given that the lint-rule would be react-specific anyway, specifying the react-specific contextually-local variables in the lint rule makes sense.