qmlweb
Investigate switching to another js parser
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?
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. :)
@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).
Please see https://github.com/qmlweb/qmlweb/issues/303 for a continuation of the discussion about the C++-based compiler. :)
