Babel-transpiled class can't extend from native class

[fatcerberus]

I'm not sure if this is even possible to fix, but I figured I'd report it just in case. 😅

Supposing one is running under an ES6-supporting engine and there is a class which is not subject to transpilation:

class C {}

If the class below is transpiled with Babel and then executed:

class D extends C {}

The result is a TypeError, constructor cannot be called without new. For example, I saw this when I tried to transpile my game with Babel before running it:

TypeError: Class constructor cannot be called without the new keyword
   at Thread (#/game_modules/thread.js:98:14)
   at DayNightEngine (@/scripts/inGameClock.js:27:9)
   at game (@/scripts/main.js:53:2)

Background: My game engine, miniSphere, was previously based on Duktape, which mainly supports ES5.1. In order to support ES6 in my toolchain, I integrated Babel into the default build process. As I'm now in the process of switching over to ChakraCore, my standard library has been refactored to export true ES6 classes; however there is still Babelized code in the wild that I would like to maintain backward compatibility with, assuming that's possible.

[babel-bot]

Hey @fatcerberus! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[loganfsmyth]

Gonna dup this with #4480.

Unfortunately fixing this is not at all easy, and it's impossible to do in an entirely spec-compliant way. We've had a few suggested solutions, but none that are particularly nice implementation-wise. Usually the expectation is that if a library publishes code with ES6-native classes, users using that library should also have Babel set up to not compile classes.

If you're trying to upgrade an existing library, I'd say changing from ES5-style classes to ES6-style classes is 100% a breaking change that requires a major-version upgrade. Seems like that is what you're saying you are doing with "my standard library has been refactored to export true ES6 classes".

[fatcerberus]

👍

Yes, my current work is already planned as a major version bump (4.8 -> 5.0) and I've even already made breaking API changes. I just figured if I could allow people to keep the transpile() step in their build scripts for the next version that would be nice, but if it's not possible I can live without the BC. Thanks for the quick response! 😃

[loganfsmyth]

No problem. Yeah, we've been trying to push everyone in the community to use https://github.com/babel/babel-preset-env because that way it's super easy to say "compile for Node" and get native classes to solve this problem.

[fatcerberus]

I definitely agree there. Unfortunately babel-standalone doesn't yet support env ☹️
babel/babel-standalone#86