Issue 1:
Input Code

See https://github.com/nikosandronikos/babel-issue for a minimal test case

The following construct results in class A having no methods on it's prototype when built with babel-preset-es2015.

const MixinName = superclass => class extends superclass {
constructor() {
super();
this.name = 'Zorg';
}

getName() {
return this.name;
}
}

class A extends MixinName(Object) {
constructor() {
super();
}

setName(n) {
this.name = n;
}
}

const a = new A();
console.log(`Hi ${a.name}.`);
console.log(`Bye ${a.getName()}.`);

Babel Configuration (.babelrc, package.json, cli command)

No .babelrc.

package.json and other configuration available at repository linked above.

Expected Behavior

The following output is expected:

Hi Zorg.
Bye Zorg.

Current Behavior

Actual output observed is:

Hi Zorg.
/Users/nikos/code/babel-issue/build/main.js:56
console.log('Bye ' + a.getName() + '.');
^

TypeError: a.getName is not a function
at Object.<anonymous> (/Users/nikos/code/babel-issue/build/main.js:56:24)
at Module._compile (module.js:541:32)
at Object.Module._extensions..js (module.js:550:10)
at Module.load (module.js:458:32)
at tryModuleLoad (module.js:417:12)
at Function.Module._load (module.js:409:3)
at Function.Module.runMain (module.js:575:10)
at startup (node.js:160:18)
at node.js:449:3

Possible Solution

I've only been playing with Babel for a couple of days so I may be way off, but it looks to me like the issue is with the _inherits(_class, _superclass); line of the MixinName definition.

Changing this to _inherits(MixinName, _superclass); appears to solve the issue.

Context

Trying to use a nice method of defining mixins that is available in ES6.

Your Environment

software
version

Babel
3.8.9

node
6.2.0

npm
3.8.9

Operating System
Reproducible on Mac OS, Win 7, and Win 10

Issue 2:
Current Babel transform, when it comes to call the parent

function _possibleConstructorReturn(self, call) {
if (!self) {
throw new ReferenceError("this hasn't been initialised - super() hasn't been called");
}
return call && (typeof call === "object" || typeof call === "function") ? call : self;
}

It's a way too poor implementation.

If we take the current basic ES6 compat syntax:

class List extends Array {}

We'll realize babel does a bad job.

var l = new List();
l instanceof List; // false

The reason is simple: Babel replace the returns and exit, without caring about userland expectations.

This is how above basic extend should desugar:

function List() {
return Object.setPrototypeOf(
Array.apply(this, arguments),
List.prototype
);
}

It's a very ad-hoc case for the initial example that currently fails, but it's good enough to understand that inheriting the prototype is the least of the problem.

Indeed, we have 3 ways to do that within a transpiled code:

// losing the initial prototype
// for polyfilled ES5+ or lower
List.prototype = Object.create(
Array.prototype,
{constructor: {
configurable: true,
writable: true,
value: List.prototype
}}
);

// using a cleaner way
// for ES5+ compliant targets
Object.setPrototypeOf(
List.prototype,
Array.prototype
);

// using a cleaner way
// that works well with
// partially polyfilled .setPrototypeOf
List.prototype = Object.setPrototypeOf(
List.prototype,
Array.prototype
);

Solved the inheritance bit, considering Babel also set the prototype of each constructor,

we need to address cases where a super call might "upgrade" the current context, like it is for HTMLELement or exotic native objects.

// native ES6 static example
class List extends Array {
constructor(a, b, c) {
super(a, b);
this.push(c);
}
}

Above case should desugar to something like the follwoing:

function List(a, b, c) {
// the super bit
var self = Object.setPrototypeOf(
Array.call(this, a, b),
List.prototype
);
// the rest with swapped context
self.push(c);
// at the end
return self;
}

which is also ad-hoc example code for the previous example.

Considering a transpiler will get the arguments part easily right, this is how previous case could be generically transpiled for arguments used in both constructors:

// to make it as generic as possible
function Child() {

// the super call bit desugar to ...
var
instance = Object.getPrototypeOf(Child)
.apply(this, arguments),
type = instance ? typeof instance : '',
// if Parent overwrote its default return
self = (type === 'object' || type === 'function') ?
// upgrade the instance to reflect Child constructor
Object.setPrototypeOf(instance, Child.prototype) :
// otherwise use the current context as is
this
;

// at this point, the rest of the constructor
// should use `self` instead of `this`
self.push(c);

// and return `self` reference at the end
return self;
}

The last problem is that modern syntax would use Reflect to create any sort of object, instead of old, ES3 friendly, .call or .apply way.

Following a past, present, and even future proof approach:

var
reConstruct = typeof Reflect === 'object' ?
Reflect.construct :
function (Parent, args, Child) {
return Parent.apply(this, args);
}
;

function Child() {

// the super call bit
var
instance = reConstruct.call(
this,
Object.getPrototypeOf(Child),
arguments,
Child
),
type = instance ? typeof instance : '',
self = (type === 'object' || type === 'function') ?
Object.setPrototypeOf(instance, Child.prototype) :
this
;

// the rest of the constructor body
self.push(c);

// at the end or instead of empty returns
return self;
}

Above solution would work with userland, exotic, or DOM constructors, and in both native and transpiled engines.