Closed Mugen87 closed 4 years ago
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;
@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 {}
.
@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).
@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.
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).
@mourner now that you're here... are you planning on adding a "module" export to Earcut
's package.json
? 😇
@mrdoob oh yes :) Let's discuss there: https://github.com/mapbox/earcut/issues/126
Ended up doing a rollup transform to cleans this up: https://github.com/mrdoob/three.js/pull/19934
This can be closed.
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:Bublé produces:
Is there a way to avoid the closure around
BoxGeometry
(see https://github.com/mrdoob/three.js/pull/17276#issuecomment-534252062)?