Uglifyjs: ES6 Template Strings are not minified

[jimblue]

Feature request
Minify ES6 Template Strings:

• remove unnecessary spaces between html tags
• remove unnecessary line break character \n

ECMA
ES6

Uglify version
v3.3.14

JavaScript input

`<a href="${url}" rel="noopener nofollow noreferrer">
      <svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet" viewBox="0 0 32 32">
          <path d="M4.527 9.819l.983-.983 10.489 8.991 10.489-8.991.983.983-11.473 9.834L4.525 9.819zM3.221 6.26A2.435 2.435 0 0 0 .782 8.688v14.624a2.428 2.428 0 0 0 2.439 2.428H28.78a2.435 2.435 0 0 0 2.439-2.428V8.688A2.428 2.428 0 0 0 28.78 6.26H3.221z" fill="currentcolor"/>
     </svg>
 </a>`

Uglify options

uglifyOptions: {
    ecma: 6,
    compress: {
        drop_console: true
     },
     output: {
         beautify: false,
         comments: false
    }
}

JavaScript output

'<a href="'+this.getShareUrl(e,n)+'" rel="noopener nofollow noreferrer">\n            <svg xmlns="http://www.w3.org/2000/svg" preserveAspectRatio="xMinYMin meet" viewBox="0 0 32 32">\n              <path d="M4.527 9.819l.983-.983 10.489 8.991 10.489-8.991.983.983-11.473 9.834L4.525 9.819zM3.221 6.26A2.435 2.435 0 0 0 .782 8.688v14.624a2.428 2.428 0 0 0 2.439 2.428H28.78a2.435 2.435 0 0 0 2.439-2.428V8.688A2.428 2.428 0 0 0 28.78 6.26H3.221z" fill="currentcolor"/>\n            </svg>\n          </a>'

[kzc]

Not a bug. ES6 template strings can contain any arbitrary string.

[jimblue]

I'm not saying it's a bug. It's a feature request 😉

[kzc]

Producing incorrect strings is not a desirable feature for a general purpose javascript minifier.

[jimblue]

Can you be more precise @kzc...

I don't see how removing unnecessary line break and space betweens tags could produce incorrect strings.

Moreover such feature as many others in uglify would be togglable by user.

The purpose of a javascript minifier is to minify, so why not try to improve this.

[kzc]

This proposal is mistakenly assuming that all template strings in a javascript program are HTML.

[jimblue]

@kzc, you've probably misread as I've never assumed all templates strings will be HTML.
I've just notice they aren't compressed by uglify, so I came here to talk about it.
So I would appreciate some constructive discussion.
This topic is totally admissible as Template Strings aren't minified.
There is solution to all problem.

[kzc]

This feature is out of scope for uglify and an ECMAScript parser toolkit generally.

You're essentially talking about implementing a complete non-ecmascript parser within uglify just for quasi HTML/JSX within template strings. Not only would one have to mark specific template strings for possible transformation with a comment annotation or some other means, the grammar is easily broken with arbitrary template ${subexpressions}.

Take a look at the uglify AST transform API to make such one off transforms for specific projects.

[alexlamsl]

@kzc I'm assuming you want this issue closed?

[kzc]

No one would likely implement a PR, so it'd remain open forever. Might as well close.

[chrisdothtml]

~There seems to be a misunderstanding that the only thing that could possibly take up multiple lines in a template string is HTML, which isn't true at all. However, this still is not a feature that should be implemented.~

~@jimblue The point of uglifying your code is to make your files smaller, and when you replace an actual line break character (one character from your filesystem's perspective) with \n in your code (two characters from your filesystem's perspective), you're actually making the resulting file bigger.~

~So, while the file may be visually smaller with this replacement, it actually ends up bigger~

EDIT: On second thought, the before/after sizes would likely be the same after gzip