Question about a generated closures.

[Mugen87]

We at the three.js team try move our code base to ES6 classes and want to use Bublé to generate ES2015 code. When inspecting the output, we noticed that Bublé produces a closure around class definitions iff the class is inherited from another one. Consider this (stripped-down) code:

class BoxGeometry extends Geometry {

	constructor( width, height, depth, widthSegments, heightSegments, depthSegments ) {

		super();

		this.type = 'BoxGeometry';

	}

}

Bublé produces:

var BoxGeometry = /*@__PURE__*/(function (Geometry) {
	function BoxGeometry( width, height, depth, widthSegments, heightSegments, depthSegments ) {

		Geometry.call(this);

		this.type = 'BoxGeometry';

	}

	if ( Geometry ) BoxGeometry.__proto__ = Geometry;
	BoxGeometry.prototype = Object.create( Geometry && Geometry.prototype );
	BoxGeometry.prototype.constructor = BoxGeometry;

	return BoxGeometry;
}(Geometry));

Is there a way to avoid the closure around BoxGeometry (see mrdoob/three.js#17276 (comment))?

[mrdoob]

Ideally we would like it to produce this:

function BoxGeometry( width, height, depth, widthSegments, heightSegments, depthSegments ) {

	Geometry.call( this );

	this.type = 'BoxGeometry';

}

BoxGeometry.prototype = Object.create( Geometry.prototype );
BoxGeometry.prototype.constructor = BoxGeometry;

[mourner]

@mrdoob @Mugen87 as far as I know, the closure is necessary in case of subclassing because superclass reference can otherwise change, leading to broken super calls. Consider this:

class Foo {}
class Bar extends Foo {}
Foo = null;
new Bar();

This code will throw if transpiled without a closure. TypeScript behaves the same way (adding a closure), and Babel probably is too.

if ( Geometry ) BoxGeometry.__proto__ = Geometry;

This line is necessary to inherit static methods.

Checks for whether superclass is falsy are necessary for compatibility, because ES allows code like class Foo extends null {}.

[mrdoob]

@mourner The ideal output I shared is the current pattern the whole library uses. We were hoping to adopt ES6 classes, and be able to produce the same ES5 build (or as close as possible).

[mourner]

@mrdoob yeah, I see, although it's unlikely to be achievable with Buble without some custom transforms — we can't sacrifice compatibility for a few more bytes that are likely mitigated by gzip.

BTW I'm wondering what you think about dropping IE11 support — any rough timelines? That would produce a lean build and make transpilation unnecessary.

[mrdoob]

we can't sacrifice compatibility for a few more bytes that are likely mitigated by gzip.

Yeah I understand. FWIW, is not about bytes, but about avoiding side effects. If the ES5 code remains the same I can go to sleep wihtout worrying that in a random config somewhere the extra closure is not changing something or affecting performance somehow.

BTW I'm wondering what you think about dropping IE11 support — any rough timelines? That would produce a lean build and make transpilation unnecessary.

The three.module.js build already dropped IE11 support (unless the user transpiles it that is).

[mrdoob]

@mourner now that you're here... are you planning on adding a "module" export to Earcut's package.json? 😇

[mourner]

@mrdoob oh yes :) Let's discuss there: mapbox/earcut#126

[mrdoob]

Ended up doing a rollup transform to cleans this up: mrdoob/three.js#19934

[mrdoob]

This can be closed.