Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

"Minify JavaScript" / UglifyJS fails without reporting error

See original GitHub issue

I’m running html-minifier 3.5.14 locally but also tried the current online version http://kangax.github.io/html-minifier/ with my code, which just does not seem to minify the javascript. I’ve narrowed down the cause to a const declaration:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <title>title</title>
  <style>
    html,
    body {
      margin: 0;
      padding: 0;
    }
  </style>
  <script>
    document.addEventListener("DOMContentLoaded", function() {
      
      const fail = [{n:"object"},];

    }); //
  </script>
</head>

<body>
Hello world!
</body>

</html>

results in

<!doctype html><html lang=en><meta charset=UTF-8><title>title</title><style>body,html{margin:0;padding:0}</style><script>document.addEventListener("DOMContentLoaded", function() {
      
      const fail = [{n:"object"},];

    }); //</script>Hello world!

It works when I change it to a plain old var.

There’s a note on SO: https://stackoverflow.com/a/47440295

UglifyJS does not support es6. const is an es6 declaration, so it throws an error. What is weird is that the package you use does not transpile its files to es5 to be used anywhere. If you want to still use UglifyJS (to re-use the configuration for example) use the ES6+ compatible version, uglify-es.

However, I don’t get an error with my local html-minfier either.

It would be nice if the user would get to see the underlying error message.

It also can't handle default function parameters, `let`, `=>`, etc. . There's a demo at http://lisperator.net/uglifyjs/ which throws errors.

Issue Analytics

State:
Created 5 years ago
Comments:10

Top GitHub Comments

4reactions

danielvaijkcommented, Dec 5, 2018

@janusz-bb, here’s a snippet of a module I wrote for one of my projects. The code belongs to a helper function that minifies HTML content (via html-minifier) rendered by Pug on a server application using Express.

const html = await new Promise((resolve, reject) => {
    res.render(page.name, page.data, (err, html) => {
        err ? reject(err) : resolve(minify(html, {
            collapseBooleanAttributes   : true,
            collapseInlineTagWhitespace : true,
            collapseWhitespace          : true,
            minifyCSS                   : true,
            minifyJS                    : (text, inline) => { return terser.minify(text).code; },
        //  minifyURLs                  :
            removeAttributeQuotes       : true,
            removeComments              : true,
            removeEmptyAttributes       : true
        }));
    });
});

Notice how I plug in Terser in the minifyJS field of the minify method. That’s how I use Terser with html-minifier. 😃

4reactions

joshribakoffcommented, Oct 3, 2018

It’s working as designed. If it cannot parse the JS it will emit it as is.

Right, again, that was acknowledged in the original issue report:

It would be nice if the user would get to see the underlying error message.

Silently failing instead of having an error or warning is egregious. I’d like to know what the use case is for a tool to silently fail when passed unsupported input?

Precisely we are petitioning for the design to change which would make the tool more reliable & save downstream users lots of wasted time & woes. Is there an actual objection to changing the design? It doesn’t seem to make much sense to expend time debating whether this is a feature request vs a bug, if that’s your intention, we’re just expressing our opinion that the current behavior is not very useful & that changing the behavior would be more useful to us.

People will end up with seemingly random unminified output with no idea why, spend lots of time hunting down why, then will end up here & expend your time posting issues… If the tool outputted a warning then at least users would be cognizant of the implications of adding es6, and would be able to make a deliberate decision to either not use es6 / disable minification intentionally.

I would like to know if you are objecting to making a change here, and the reason why? Simply replying with facts that were already stated in the original issue report are not particularly helpful. I think it would be more helpful to outright say that you’re not supporting the use case (and if so why), or acknowledge that the current workflow can be improved so that someone can start on a PR? Instead it seems to me like we may be spinning our wheels here without any resolution one way or the other, and I have to wonder to what end.

This is a great tool & I while I cannot speak for others, I feel the intention of the community is to make it even greater, not debate semantics.