A big thank you to everybody working on this! @Krinkle: I'll follow your recommendation to include the slint-config-wikimedia package, thanks.

Thank you for looking into this and sorry that I have caused work by creating a bug report for a behavior that is not supported by design. To my defense: I did check at https://doc.wikimedia.org/mediawiki-libs-Minify/master/ (the README.md file) whether any restriction in supported Ecmascript versions is listed. Thanks for pointing to the commonly agreed eslint configuration disallowing certain new features in the MediaWiki universe - I didn't know that.

Thank you! I just tested whether the newest master branch (cfe7568b) fixes the problem by copying the content to the MediaWiki 1.39.5 vendor/wikimedia/minify folder and purging a page. I'm still getting the Uncaught SyntaxError: "" string literal contains an unescaped line break error.

Adding /*@nomin*/ close to the end of the file to prevent minification helps as workaround.

I can imagine that it's quite hard to write a fast minifier that can cope with alreay minified complex input, it might be an alternative to reconsider https://phabricator.wikimedia.org/T346701 .

The bug report https://phabricator.wikimedia.org/T277161 might be related but as it is marked resolved in an earlier version I assume it's something else.

• Original:
  original.js942 KBDownload
• Minified:
  minified.js853 KBDownload

To follow up on my old bug report I re-checked the functionality in MediaWiki 1.39. Function recursiveTagParse( $text, $frame = false ) still doesn't escape the ampersands but the function description clearly says that it only returns "half-parsed HTML". In contrast, the function recursiveTagParseFully( $text, $frame = false ) returns "fully parsed HTML" and I can confirm that this function does encode ampersands correctly. So I propose to close this task.

I stumbled upon this report when trying to solve my MediaWiki 1.31 utf8 issues with emojis. My MariaDB tables mostly had the utf8 (utf8mb3) encoding active causing the problem. I realized that the decision was made to recommend/support binary encodings of text column for MariaDB/MySQL only (containing UFT-8 raw data). Despite I would have preferred to switch to utf8mb4, I will stick to that recommendation and changed my columns to the up-to-date MediaWiki SQL schema.

For me, the following fix works (although I admit it's not a very general solution):