This task does not represent a bug or feature request for the Minifier library itself. Rather, it describes how MediaWiki core might use that library.

The core use-case would be solved by T36958.

Untagging MediaWiki-extensions-Gadgets, since Gadgets already leverage ResourceLoader and its caching/compression features. This task is about user scripts which are in MediaWiki core.

In terms of traffic numbers and wholistic cost/benefit numbers, gadgets are more popular than user scripts. As a user script gets more popular, the incentives we try to create in the platform are for the user script to become a gadget. This has numerous benefits, such as:

• collaborative ownership,
• secure editing restrictions and auditing/visiblity through patrolling and tooling,
• higher care from Global interface editors and MediaWiki developers (this is a recursive or meta statement, since the reason for it is dependent on itself, we care more because it has higher impact, and it has higher impact because we assume a well-cared-for-and-popular user script feature is likely to become a gadget)
• efficient and fast loading of dependencies.
• efficient conditional loading (T63007).
• native localisation (in Gadgets 2.0, still WIP).
• bundling of multiple files into a single compressed response.
• minification.
• CDN caching.
• browser caching.
• etc.

As such, from a cost-benefit perspective, I don't think we should invest into minor improvements for user scripts that don't fundamentally enable new abilities. Adding support for minification doesn't expand the audience reach or technical abilities of the user script system. The benefit is thus of only small and mostly invisible value to the community, but, will require indefinite ownership and maintenance for the platform, and adds new complexity for all editors to deal with.

For example, how to undo the minification when debugging and editing scripts? How does debug mode propagate to importScript? Will we add source maps support? Or some other way to dynamically skip minification? Do we impose a restriction to only support ES6 user scripts (like we impose on gadgets) or do we allow some way to opt-out from minification if new syntax is used? Or do we break existing imports after a user script starts to make use of new JS syntax?

From a more neutral perspective, we can look at stated benefit and try to measure it:

Benefits: reduce bandwidth, fast loading.

I believe that, today, action=raw is implemented such that minification would have very little impact. This is because action=raw is rarey used for logged-out users (we prefer gadgets there for security and performance reasons), and for logged-in users it currently does not support caching. This means importScript() is going to the server on every page view, which brings significant latency and request/response headers. The few extra bytes from it being unminified are not what stands out there today in terms of performance.

As an example, the popular Wikiminiatlas.js script contains 27KB of decompressed source code. This is currently transferred in 10.8KB with gzip. Applying the latest wikimedia/minify/bin/minify js command and compressing the result, yields 8.9KB. It saves about 1KB of data. However, the browser also incurs another 2.3KB in request (1.3KB) and response (1.0KB) headers.

See also: T279120: Make index.php?action=raw CDN cacheable for both logged-in and logged-out for import script use case

I got lost in the long list of declined/duplicate tasks about this. Just to make the current task visible: T36958: User-level gadgets (aka "Gadgets 3.0").