Unwind IIFE class patterns

[Andarist]

feature request

ES5

Uglify version (uglifyjs -V)
latest (testes on uglify-es too)

JavaScript input

var MyClass = function () {
  function MyClass() {}

  MyClass.prototype.method = function method() {};

  return MyClass;
}();

instance = new MyClass()

The uglifyjs CLI command executed or minify() options used.

uglifyjs --toplevel -mc passes=3,unsafe

JavaScript output

var n=function(){function n(){}return n.prototype.method=function(){},n}();instance=new n;

Requested JavaScript output
Something along this:

function n(){};n.prototype.method=function(){},instance=new n

[alexlamsl]

You may implement this by enhancing inline:
https://github.com/mishoo/UglifyJS2/blob/00f509405b44882bab5d63d97caacb21691cdad6/lib/compress.js#L3367-L3406

[kzc]

It's more complicated than it first appears. Hoisting the function may require renaming it or it may conflict with a symbol in the outer scope. Presently compress and mangle are two independent transform phases.

In the current code base function inlining only works on single statement functions (this includes an AST_Sequence statement - which is useful). If an inline candidate function contains a function definition or a variable declaration then it breaks that assumption since you'll have more than one statement. Also, inlining of functions with multiple statements would may involve introducing a block in the outer scope.

All of this could be done of course, it's just not easy to get all the corner cases right.

[Andarist]

Hoisting the function may require renaming it or it may conflict with a symbol in the outer scope.

I guess it depends how detection of the "class pattern" can be done. Or is it possible to safely do such optimization on things other than "class pattern".

Talking purely about this specific scenario of "class pattern" we do not have to introduce any new identifier to the outer scope. The IIFE could be unwinded to:

var n = function (){};n.prototype.method=function(){},instance=new n

which doesnt introduce any new identifiers than whats outputted today.

Also, inlining of functions with multiple statements would may involve introducing a block in the outer scope.

could u elaborate?

All of this could be done of course, it's just not easy to get all the corner cases right.

Agreed, I would love to help with implementing this, but Im afraid I'm just not able to dive to yet another codebase right now 😢 .

Possible gains from having this feature implemented are probably quite big in es6 classes / TS world (most of the newer projects), so I hope somebody could try to work on this some day.

EDIT:// Im not sure what phases of the compiler are there, but this should ofc should be performed after dropping #__PURE__ calls etc

[kzc]

If a multiline function is inlined/hoisted from within a single statement if body, for example, an AST_BlockStatement would have to be introduced to replace the AST_SimpleStatement. Just an implementation detail one would discover if implementing the feature. You can view the uglify AST with this CLI option: uglifyjs code.js -o ast.

An alternative approach - scan each function to see whether it produces any external side effects beyond the function and mark it internally as equivalent to /*#__PURE__*/ and let the existing compress transforms do the rest. In your down-leveled class example in the top post it only alters a locally introduced function definition (adds a prototype method), but does not have any external side effects beyond the function. Easier said than done, of course.