-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Explicitly bind wrapping IIFE to window for ES5 strict mode compatibility #1398
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here (e.g. What to do if you already signed the CLAIndividual signers
Corporate signers
|
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.
This all makes sense to me. I'm going to run tests on our build bot. You will also need to fill out a Contributor License Agreement and respond to the CLA bot before I am allowed to merge this.
Thanks!
All tests passed! |
Thanks! I've signed the CLA. |
CLAs look good, thanks! |
Excellent, thanks for the fantastic library by the way, I've been using for years across various projects/companies without issue and found the documentation top notch. Unfortunately this was the first time I've been forced to use it in a pre-packaged context like this. |
Thank you for the kind words. We're glad to be doing this. And thanks for the contribution as well! I forgot one thing, though. You will need to add yourself to the CONTRIBUTORS file (in alphabetical order), and you'll need to add an entry to the AUTHORS file, as well. If you signed the CLA as an individual, you add yourself to AUTHORS. If you are covered by a corporate CLA, you add your company to AUTHORS. Thanks! |
Have now added myself to AUTHORS and CONTRIBUTORS. Should be good to merge! |
Thank you for your contribution! |
Cherry-picked to v2.3.6. |
I came across the following issue while using Shaka as a dependency of another pre-bundled player library that was delivered to my company as a single, minified UMD-wrapped package without a package.json and therefore no resolvable dependencies. Due to the nature of a UMD library, all dependencies are wrapped inside it so that it can be used as a
<script>
tag without the need for a build process. I anticipate many other video players may deliver Shaka to customers like this to avoid complexity for their customers.I will be following up with the authors of the player to see if they can provide a commonjs build instead with a resolvable list of dependencies, but I can't see any downside of adding the suggested changes below and making Shaka more robust in the process.
Thanks!
Description
Shaka assumes that
this
within the top-level IIFE will be bound towindow
in a browser environment.This works correctly as long as Shaka is a top-level dependency (node_module) of an ES6+ project and therefore ignored from babel transpilation. However, when it is part of some other bundle which is transpiled from ES6 to ES5 before being consumed, this process will add the following:
As per the strict-mode specification,
this
isundefined
within an implicitly called IIFE.Shaka is then broken, as various pieces of code such as
window.console
become lookups on undefined.To address this, we can explicitly bind the IIFE to the window, and Shaka will function correctly regardless of whether it is being evaluated in a strict mode context or not.