Skip to content
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

Pin @babel/plugin-transform-classes to v7.0.0-beta.35 #216

Merged
merged 12 commits into from
Apr 26, 2018

Conversation

bicknellr
Copy link
Member

@bicknellr bicknellr commented Apr 24, 2018

babel/babel#7020 (included in v7.0.0-beta.36) breaks our assumptions about how babel will transform ES6 classes. Particularly, it changes the way that compiled ES6 classes which extend (what babel assumes to be) native constructors such that the subclasses no longer call into the parent classes' constructors. This is allows the transformation to avoid a specific type of error when extending native constructors: most must be constructed with new (or super / Reflect.construct, which aren't available in ES2015) and will throw when called using call or apply. However, the polyfill needs the user to call into the polyfilled constructor to retrieve the exact element which is being upgraded and so that the user's constructors are called with that specific element as this.

This PR manually assembles the set of transforms in @babel/preset-es2015 (with our particular configuration) for the purpose of being able to pin @babel/plugin-transform-classes to v7.0.0-beta.35 .

  • tests

babel/babel#7506 - a bug about this issue
babel/babel#7533 - related PR to fix bug above

[require('@babel/preset-es2015'), {modules: false}];
const customBabelPresetEs2015 = {
plugins: [
[require("@babel/plugin-transform-template-literals"), { loose: false, spec: false }],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all of these parameters are default false except for the regenerator ones? Could just leave off the ones that aren't changing a default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You were right, almost all of these were the defaults.

@@ -29,8 +29,30 @@ import isWindows = require('is-windows');
// minifying but not compiling?

// Syntax and transform plugins for ES2015.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add note linking to bug about class plugin and mention its why we aren't using the preset.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

@@ -168,7 +190,7 @@ export function jsTransform(js: string, options: JsTransformOptions): string {
}
if (options.compileToEs5) {
doBabelTransform = true;
presets.push(babelPresetEs2015NoModules);
presets.push(customBabelPresetEs2015);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

plugins.push(...? Probably works either way, but seems more clear now that it's not technically a preset.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT, this would change the order? https://babeljs.io/docs/plugins/#pluginpreset-ordering

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://babeljs.io/docs/plugins/#creating-a-preset kinda makes it sound like this counts as a preset.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a preset is just an array of plugins, and yes it does affect ordering (if you look above in the transform functions I mentioned how things are ordered). I guess this is fine, and it definitely won't change the ordering!

@aomarks
Copy link
Member

aomarks commented Apr 24, 2018

Also mind adding a CHANGELOG entry? Should probably mention it on build, CLI, and polyserve since the bug affects all of those end uses, and each will need to be released to pick it up because we do = pinning on build and the other pre- packages.

@aomarks
Copy link
Member

aomarks commented Apr 24, 2018

If there's a straightforward way to check that the bad transform is not happening, mind adding a regression test in js-transform_test?

@bicknellr
Copy link
Member Author

bicknellr commented Apr 24, 2018

I've added a test that checks for whether or not the empty function on this line (the broken constructor) is injected into the output when creating a class that extends from HTMLElement.

"@babel/plugin-external-helpers": "^7.0.0-beta.46",
"@babel/plugin-proposal-async-generator-functions": "^7.0.0-beta.46",
"@babel/plugin-proposal-object-rest-spread": "^7.0.0-beta.46",
"@babel/plugin-syntax-async-generators": "^7.0.0-beta.46",
"@babel/plugin-syntax-dynamic-import": "^7.0.0-beta.43",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to bump this one to 46 also, just to keep everything else at the same version.

`);
const result = jsTransform(input, {compileToEs5: true});

assert.notInclude(result, "function Wrapper() {}");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about checking for wrapNativeSuper, since it's the name of the helper function that contains this line? Maybe less brittle.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's a better idea; the whitespace in this string was making me a bit worried: function Wrapper() {} vs. function Wrapper(){} etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about checking for both?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(the wrapper function thing and wrapNativeSuper)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just wrapNativeSuper is fine. If you did do both, make sure it's an or, since an and would be more brittle.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'll just do wrapNativeSuper then.

Copy link
Member

@aomarks aomarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

@aomarks
Copy link
Member

aomarks commented Apr 24, 2018

We should probably test with shop or something, just to make sure it actually works at runtime. Like I could imagine a breakage due to the helpers and the transformer being out of sync.

@bicknellr
Copy link
Member Author

I've been trying with a polymer init-created PSK, manually modified to force the custom elements polyfill and w/ UA spoofed to IE11. I think it's working as expected but I'm going to ask @keanulee to double check for me since he has better knowledge of the conditions that lead to this problem.

Copy link
Contributor

@keanulee keanulee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested branch locally, LGTM

@bicknellr
Copy link
Member Author

@keanulee thanks! I was just about to walk over and ask. :)

Copy link
Contributor

@usergenic usergenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis looks good. Only a couple of uncorrelated WCT test timed out on different VMs. Definite transient errors; doesn't warrant another run at CI if there's no more changes for this PR.

@bicknellr
Copy link
Member Author

I'm going to revert the last commit. I was hoping it was going to make these pass but since it's not helping here I don't see any reason to include it.

@bicknellr bicknellr force-pushed the pin-babel-plugin-transform-classes branch from e04cf2f to 2db915c Compare April 25, 2018 18:47
@usergenic
Copy link
Contributor

if you merge in master you'll get unit and integration tests split out. maybe easier to see whats going on

@bicknellr
Copy link
Member Author

Ok, I'll try that.

@usergenic
Copy link
Contributor

Russell, I updated travis.yml on master to reduce sauce session contention and got 4 green travis runs on the first try in a long time. Merge master again for that goodness.

@usergenic
Copy link
Contributor

@bicknellr I went ahead and merged master into this branch to get that effect. Hopefully will just see green CI in 20 minutes here.

@bicknellr
Copy link
Member Author

@usergenic I just saw that PR - awesome! Anxiously awaiting the Travis results: so far 3 for 3.

@bicknellr bicknellr merged commit 3c2ac01 into master Apr 26, 2018
@bicknellr bicknellr deleted the pin-babel-plugin-transform-classes branch April 26, 2018 03:03
@bicknellr
Copy link
Member Author

Thanks so much for figuring that out!

@javatheist
Copy link

Pls unpin.

justinfagnani pushed a commit that referenced this pull request Jul 10, 2018
…cates (#216)

* Properly key converted documents by original url, correct destination

* remove unneccesary template string wrapper

* respond to justin review feedback

* handle ConvertedDocumentFilePath conversion better

* create shouldConvertDocument() method

* update upsteam test format
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants