tcpserver.js does not propagate mjml compile errors for mjml >= 3

mjml >= 3 returns its results in a {errors: [], html: ""} object. https://github.com/liminspace/django-mjml/commit/086ffdc22ac7b4ef78802061efaacf6ffc36928b added support for mjml >= 3 by using the result.html for the output; however, the errors key in the mjml compilation result is never checked.

If mjml has a compile error, this behavior can result in blank emails going out, which is problematic. It would be much better to loudly throw an error if mjml fails to compile. Throwing errors would help to prevent that kind of reputation-harming email noise.

This alternative handleConnection function throws a RuntimeError if mjml encounters an mjml compile error:

function handleConnection(conn) {
    conn.setEncoding('utf8');
    conn.on('data', function(d) {
        var result, html;
        try {
            result = mjml.mjml2html(d.toString());
            if (result.errors.length) {
              html = JSON.stringify(result.errors, null, 2);
              conn.write('1');
            } else {
              html = result.html;
              conn.write('0');
            }
        } catch (err) {
            html = err.message;
            conn.write('1');
        }
        conn.write(('000000000' + Buffer.byteLength(html).toString()).slice(-9));
        conn.write(html);
    });
    conn.once('close', function() {});
    conn.on('error', function(err) {});
}

If you wanted to preserve backwards compatibility to older versions of mjml as the current tcpserver.js has, this would need to be modified.

[yourcelf]

mjml doesn’t distinguish between error level (“errors” vs “warnings”), but with default options it is possible to have both errors and html output in the compiled result.

mjml2html does accept an options argument which could include {validationLevel: "strict"}, which causes it to throw an exception on the presence of any error - so that’s another approach that could be taken to ensure that errors are thrown, rather than inspecting the errors array.

For my use case, I’d much prefer get an exception and not send an email if there’s any possibility the email rendering was incomplete, even if it did render with warnings. In my setup now I’m running with my own version of tcpserver.js to get that behavior, so it isn’t a burden to me if you think it better for django-mjml to have a more lax setup.

[liminspace]

@yourcelf, this issue is done in next release 0.5.0. Now you can check it in develop branch. Just set up mjml option level/validationLevel with strict value, see readme.