Investigate switching to another js parser

[ChALkeR]

E.g. acorn or esprima.

[ChALkeR]

Redoing the parser as an acorn plugins looks like a way to go.
This will make it more maintainable, and will remove the dependency on the dead uglifyjs@1.

It also produces the tree in the standardized estree format, shared between multiple parser.

That should also help us make a decent linter for qml.

/cc @akreuzkamp, @Plaristote, @stephenmdangelo, what do you think?

[ChALkeR]

I started a very basic POC in the acorn-qml repo.

[akreuzkamp]

Imo it's not worth it. As you already know, I want to use Qt's very own QML parser on the long run. Before we start any actual work on porting to another parser, I would like to have a discussion about that. In fact, there's already quite some code for that and it allows us to do quite a lot more, than just parsing (which is compiling ;)).

But it also means requiring native code for pre-parsing unlike gulp-qmlweb, which "only" requires nodejs.

But I don't want to stop you of course, if you feel to do so ;)

I'm going to open a discussion about my approach soon. :)

[ChALkeR]

@akreuzkamp The thing is, I want to keep QmlWeb usable from the client-side only, i.e. without the help of server-side parsing. And even with the server-side parsing, it would be great if that wouldn't require compilation of a native add-on and/or installing Qt on the server =).

Also, a decent parser would allow us to implement linting for *.qml files, perhaps even on top of eslint — something that would not just fail on parsing errors, but which would highlight bad code formatting etc.

Also, I'm thinking about coupling a QML parser together with Babel, that would allow to use newer ECMAScript in qml files (i.e. transforming QML with newer ECMAScript syntax to QML with supported syntax).

[akreuzkamp]

Please see qmlweb/qmlweb#303 for a continuation of the discussion about the C++-based compiler. :)

[lygstate]

acorn+1