Print error details if an error occurs during compilation

[ulikoehler]

I'm currently having some severe issues trying to get flylatex to run behind an NGinx reverse proxy on my VPS.

When trying to compile, the application just crashes -- I tracked down the bug, it's because of (IMO) incorrect behaviour of fs-extra, see jprichardson/node-fs-extra#38 .

However, even after I fixed it, I didn't find the flylatex error messages very helpful -- no detailed error message was console-logged, and the webinterface also printed only "An error occured before or during compilation", without any details.

This PR fixes this by console-logging errors and by printing the error details on the web interface.

[ulikoehler]

I hope you don't mind if I added another feature in the same pull request (--> there's no need to merge intersecting changes), this one adds a fs.exists-check on the PDF output file to produce a better error message if LaTeX just failed compilation.

[ulikoehler]

The node-fs-extra pull request has now been merged. I'll submit another pull request to update the node-fs-extra dep to the latest version.

EDIT: Ah, sorry, missed that you specified a dep version wildcard. I'm not entirely sure if this is a good idea in the long term, but at least for now it spares anyone from manually updating versions all the time

[ulikoehler]

Sorry for self-bumping, but I'd be grateful if you could review and merge this!

[alabid]

Hey @ulikoehler , thanks for the pull request but not everyone wants to see errors or error types in the console. Initially, all errors were being sent to STDOUT. But after a while (and some complaints about too much logging), only the most crucial errors were being displayed.
Also, whenever the error "An error occured before or during compilation" occurs, there's information about the error in the compilation logs (See View Logs). Besides, errors on the console can be seen by the administrator but not necessarily by the users. So the logs are more helpful after all.

[ulikoehler]

@alabid Thanks for your feedback. When I started using flylatex however, it wouldn't work and had numerous bugs. Until now, it was not possible to even show a PDF appropriately. Besides that, flylatex left a pile of tmpdirs in /tmp that weren't cleaned up properly. I adressed some of the issues in my pull requests, even if they didn't solve all the problems. One of the aspects why it was really, really hard to debug is because of logging not being done. Please use a proper logging framework (there are many of them, I sometimes use log4js) instead of preventing anyone from debugging the code instead of errors. You can then set the loglevel instead of simply omitting to log it (even if I would always enable error logging on the console, especially for system errors, whereas LaTeX errors should probably be warnings).

Please note that because of these and other severe issues with flylatex that would have taken weeks to figure out, including the collaborative text editing component being not even close to what EPLite can do, I developed my own, lightweight alternative as an EPLite plugin:
https://github.com/ulikoehler/ep_etherlatex

This might not suit all usecases, but IMO it solves all the major issues with flylatex at the moment:

• EPLite realtime editing, chat and plugins
• Does not impose a specific DB like MongoDB (works with SQLite, MySQL, LevelDB
• Does not leave any traces behind (/tmp deleted)
• Compiles twice, for BibTeX etc (not sure if FlyLaTeX does that)
• EPLite is well-tested. the ep_etherlatex codebase is small and has fewer possible problems
• Error log is shown in place of the PDF if neccessary.

Caveats:

• Currently the PDF (or the log in case of errors) is displayed in another tab/window, or downloaded if the browser doesn't support viewing.
• If a PDF is produced, there is no way to see the logs
• No document management beyond what EPLite does
• Internal errors not handled properly in all cases, pdflatex is assumed to be installed (probably the errors will show in the log anyway)

I hope you understand that even if I liked to use flylatex, I only scratched the surface of bugfixes and caveats, because I needed something that just works(TM), in limited time, of course. Hopefully FlyLaTeX will be more robust and debuggable in the future.