Pluggable extensions support?

[nzakas]

Just curious if you would consider supporting JSX syntax behind a flag (off by default)? If so, I'm willing to create a pull request for it.

I'm asking because I'd like to use Acorn in ESLint.

[marijnh]

How much extra code are we talking about? See also https://github.com/RReverser/acorn-jsx

[nzakas]

Best guess is around 400 lines.

Yup, I saw acorn-jsx. It has the same problem as esprima-fb in that it always lags behind the latest version due to needing to re-patch each time. I was hoping to find a solution where that wasn't the status quo.

[sebmck]

@nzakas Except esprima-fb is actually bleeding edge and has support for more features than esprima. acorn-jsx is updated as regularly as possible and rarely lags behind.

[marijnh]

400 lines is quite a bit of noise. I'm not interested in including this in the core for a non-standard extension.

One possibly promising direction would be to allow client code to hook into (certain) 'unexpected token' scenarios (for example at the start of expressions and statements), and define extensions by doing their own parsing and then returning a suitable replacement expression or statement. This isn't trivial, and would involve exposing more of the parser internals (which is bound to get somewhat ugly, given Acorn's use of static variables), but it would be pretty cool, allowing various extensions without forking the core.

[nzakas]

Okay, thanks for considering it, I completely understand. An extension mechanism would certainly be awesome.

[RReverser]

Looks like we might reinvent Sweet.js on top of Acorn if we go this way.

[angelozerr]

Looks like we might reinvent Sweet.js on top of Acorn if we go this way.

and if I understand the idea, typescript and coffescript too? If it that it should be amazing!

[RReverser]

TypeScript/Flow/AtScript/other clone - maybe. CoffeeScript - doubt it.

[sebmck]

@angelozerr It would only allow extensions to JS syntax. It'd be easier to write an entirely new parser if you were to have a completely different syntax (such as CoffeeScript).

[jamiebuilds]

One possibly promising direction would be to allow client code to hook into (certain) 'unexpected token' scenarios (for example at the start of expressions and statements), and define extensions by doing their own parsing and then returning a suitable replacement expression or statement.

While I'm a big fan of this idea, an alternative would be to add a build step which compiles different versions of the same parser. Lodash has done this to great success.

[RReverser]

@thejameskyle That would mean that one library would need to support all the existing and future possible dialects/extensions of JavaScript, which would seriously violate single responsibility principle.

[jamiebuilds]

which would seriously violate single responsibility principle.

Full agreement here, just seemed like @marijnh was hesitant to expose acorns internals.

[marijnh]

Not hesitant in that I think it would be a bad idea. Just that factoring things into a sane API without adversely affecting performance is going to be a finicky job, for which I'm not going to have time in the near future.