-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove ClassCallCheck, possibleConstructorReturn in loose mode #4850
Conversation
Codecov Report
@@ Coverage Diff @@
## 7.0 #4850 +/- ##
==========================================
+ Coverage 85.21% 85.21% +<.01%
==========================================
Files 284 284
Lines 9958 9966 +8
Branches 2780 2785 +5
==========================================
+ Hits 8486 8493 +7
Misses 971 971
- Partials 501 502 +1
Continue to review full report at Codecov.
|
Wasn't it |
Both actually. I'm looking for a way to say "hey, don't worry about protecting classes, they are internal to my module anyway". |
Not that I have anything against this change, but I'm just curious to know what the use-case is @developit. Performance? |
Performance and file size. I use codemods or avoid classes entirely, with this in place it would be more viable. |
@developit oh and you can also check out babili's plugins + babel codemods |
Part of me wonders if these things should just be part of |
@hzoo think babili would cover stripping these? That would get me to upgrade to 6 for sure! 😂 |
@DrewML huge fringe benefit of doing that would be that the Perhaps another option is a |
I think Babel 5 docs on loose mode were:
I kind of interpret that as "generate the minimal amount of changes to make the code work, and ignore edge-cases where someone could do something bad" |
That is certainly how I think of it. It would be a very compelling option to have handy, at least for me. Tends to be like 300-500 bytes, which for small libs like preact is a heck of a lot (10%!). |
@hzoo Thoughts/Opinions on combining this into loose mode? |
We could? I guess it would be a "breaking change" still? although most that use loose mode wouldn't care about it anyway |
It be breaking for anything that is relying on calling constructors to throw (for whatever reason, I can't think of a good one, maybe some over-testing?). It's just the preset though and I would guess as you said, those are not the people running in loose mode. Also since loose was only added in 6.13 (?) it seems like it'd be not quite as widely used yet. |
This changes the plugin not the preset so it would affect everyone using the option which should of been there since the beginning? Yeah it's removing a throw check so it wouldn't break anything in the opposite way |
I guess this kind of leads to the bigger question of "what is a breaking change" in these options. In theory, we could never add any features to Semver is hard :( |
Using I would like for Babel to generate code that is as close to ES6 compliant as possible under normal circumstances, then use loose mode to drop every line of code that is not strictly necessary to make stuff just work. It means in loose mode you can do stuff that is against spec... But probably you will dev in strict mode and catch such uses there. Once it's in production, use loose mode for max. performance. Having a single toggle on the preset would be infinitely more valuable than having to control each plugin separately. |
Also makes fall-through from presets like |
Yes it should although fyi |
You know I'm behind on all that stuff (still using 5 in places haha) |
😅 can someone just make the auto upgrade from 5 to 6 bot |
@hzoo still produces larger output for some reason, need to look into why. I'm basically only using babel to convert |
7677c86
to
6b31d13
Compare
@@ -0,0 +1,40 @@ | |||
function _inherits(subClass, superClass) { if (typeof superClass !== "function" && superClass !== null) { throw new TypeError("Super expression must either be null or a function, not " + typeof superClass); } subClass.prototype = Object.create(superClass && superClass.prototype, { constructor: { value: subClass, enumerable: false, writable: true, configurable: true } }); if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to remove the checks here too?
function _inheritsLoose(subclass, superClass) {
subClass.prototype = Object.create(superClass && superClass.prototype);
subClass.prototype.constructor = subClass;
if (superClass) {
subClass.__proto__ = superClass;
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely. My view here is that people using loose mode classes are just asking for a direct replacement for the ES5 equivalent.
function C() { | ||
woops.super.test(); | ||
|
||
var _this = _B.call(this) || this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can drop || this
as well
6b31d13
to
cdca54a
Compare
@hzoo Loving what you are doing here! Can't wait for it to be merged and released! |
|
||
function A(track) { | ||
if (track !== undefined) { | ||
var _this = _B.call(this, track) || this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and remove || this
I guess?
(function (subClass, superClass) { | ||
subClass.prototype = Object.create(superClass && superClass.prototype); | ||
subClass.prototype.constructor = subClass; | ||
if (superClass) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on also removing this check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
because we would assume superClass is not null? like class extends null
or class extends expression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good call, I was thinking it would always be appropriate to throw an exception but I stand corrected! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok we can just assume in loose mode that the superClass is non-null and has a prototype to get
(function (subClass, superClass) {
subClass.prototype = Object.create(superClass.prototype);
subClass.prototype.constructor = subClass;
subClass.__proto__ = superClass;
})
@@ -377,6 +377,16 @@ helpers.inherits = template(` | |||
}) | |||
`); | |||
|
|||
helpers.inheritsLoose = template(` | |||
(function (subClass, superClass) { | |||
subClass.prototype = Object.create(superClass && superClass.prototype); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we would be able to remove the check here too then @developit? superClass &&
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup
woops.super.test(); | ||
|
||
var _this = babelHelpers.possibleConstructorReturn(this, _Foo.call(this)); | ||
var _this = _Foo.call(this) || this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we remove || this
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do, we'd have to remove the whole var _this =
(and all the _this
s) too. I think this is fine for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm. this seems important.
woops.super.test(); | ||
|
||
var _this = babelHelpers.possibleConstructorReturn(this, _Foo.call(this)); | ||
var _this = _Foo.call(this) || this; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do, we'd have to remove the whole var _this =
(and all the _this
s) too. I think this is fine for now.
Ok will merge and someone can do #4850 (comment) as a followup issue/PR |
Also something about travis is messed up (circle ci passes + local) |
@hzoo Is there a way to test this in my project before it is released to NPM? |
I could some better docs for this (or a utility to make it easy) but yeah you can just overwrite your node_modules? Like literally replace the 2 files that we changed. You can probably just run the src/index.js through babeljs.io/repl and then replace the lib/index.js in node_modules and add that helper to test it |
@hzoo Ok. I guess that's a bit too far outside of my comfort zone :) I guess I'll wait until the next alpha makes it to NPM. :) |
cc @developit