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

Changes UMD callsite to be more likely to pass in the intended object. #10477

Merged
merged 2 commits into from Oct 29, 2019
Merged

Changes UMD callsite to be more likely to pass in the intended object. #10477

merged 2 commits into from Oct 29, 2019

Conversation

MicahZoltu
Copy link
Contributor

@MicahZoltu MicahZoltu commented Sep 21, 2019

Q                       A
Fixed Issues? Fixes #10476
Patch: Bug Fix? Yes
Major: Breaking Change? No
Minor: New Feature? No
Tests Added + Pass? No
Documentation PR Link
Any Dependency Changes?
License CC0/Unlicense/MIT/WTFPL/whatever you want.

See #10476 for details.

Note: This PR should be considered pseudocode and used as an illustration of the proposed fix. I do not know nearly enough about this project to know if this is an appropriate solution to the problem, nor do I have the confidence to update the tests appropriately.

@nicolo-ribaudo nicolo-ribaudo added area: modules PR: New Feature 🚀 A type of pull request used for our changelog categories labels Sep 21, 2019
@@ -27,7 +27,7 @@ const buildWrapper = template(`

GLOBAL_TO_ASSIGN;
}
})(this, function(IMPORT_NAMES) {
})(globalThis || window || this, function(IMPORT_NAMES) {
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't this throw a globalThis is not defined error in browsers with modules supprot (where the code is executed in strict mode) but without globalThis support?

Those browsers are Edge 16, Firefox 60-64, Chrome 61-70, Safari 10.1-12.0 and Opera 48-57

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
})(globalThis || window || this, function(IMPORT_NAMES) {
})(
typeof globalThis === "object" ? globalThis
: typeof window === "object" ? window
: this,
function(IMPORT_NAMES) {

Copy link
Member

Choose a reason for hiding this comment

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

Definitely need Nicolo's suggestion, but we should use self instead of window to support workers as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

typeof globalThis === "object" ? globalThis
: typeof self === "object" ? self
: typeof window === "object" ? window
: typeof global === "object" ? global
: this

Is that too overboard on trying? I think there are environments where window is defined but not self or globalThis (older browsers), and older versions of NodeJS only define global I believe. Does it make sense to fallback to this at the end? Perhaps for test environments the this fallback is valuable?

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 self is enough. IE has supported it forever. As for global, let's assume people can just load a globalThis polyfill in node. Client side we have to worry about bytes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The suggested changes have been applied and the code rebased. Anyone can feel free to takeover and finish this up (e.g., update the tests). I'm on Windows and this repo appears to have a number of issues with Windows so I doubt I'll be able to finish it.

@nicolo-ribaudo
Copy link
Member

After the code changes, you can run make bootstrap and OVERWRITE=true make test to update the failing tests

@MicahZoltu
Copy link
Contributor Author

After the code changes, you can run make bootstrap and OVERWRITE=true make test to update the failing tests

Unfortunately I'm on Windows, so I don't have make.

@MicahZoltu
Copy link
Contributor Author

Also the pre-commit hook is failing on my machine in what appears to be unrelated code, so the current commit is pushed with --no-verify.

@jridgewell
Copy link
Member

Pushed updated tests.

@babel-bot
Copy link
Collaborator

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/11679/

@jridgewell
Copy link
Member

Actually, do we even need a globalThis check? The global parameter is only used if we're not using requirejs and we're not in node. That means we're in browser mode, and self will be enough.

@MicahZoltu
Copy link
Contributor Author

MicahZoltu commented Sep 24, 2019

globalThis is intended to be the future of the universal global object. It feels like a good idea to try that first, as one day (far, far in the future) window, self, and/or global may be deprecated.

Glancing at the globalThis docs on MDN it also references frames in some situations, not sure if we need to or should handle that as well?

@JLHwung
Copy link
Contributor

JLHwung commented Oct 15, 2019

Unfortunately I'm on Windows, so I don't have make.

gnuwin32 works for me on Windows.

@MicahZoltu
Copy link
Contributor Author

Does the PR build process really take over 21 days to complete, or is it stalled? If it is stalled, what can be done to restart it so we can move forward with this PR?

@jridgewell jridgewell closed this Oct 15, 2019
@jridgewell jridgewell reopened this Oct 15, 2019
@jridgewell
Copy link
Member

I kicked the build servers. It definitely shouldn't take this long.

@MicahZoltu
Copy link
Contributor Author

The Travis build failure does not appear to be related to the changes I have made in this PR. Can someone more familiar with this project glance at the build failure and help me understand how they are related to these changes if they are?

@MicahZoltu
Copy link
Contributor Author

The build failure doesn't appear to have anything with these changes. Can I get someone familiar with the project to validate that claim?

MicahZoltu and others added 2 commits October 24, 2019 15:31
Fixes #10476
Note: This PR should be considered pseudocode and used as an illustration of the proposed fix.  I do not know nearly enough about this project to know if this is an appropriate solution to the problem, nor do I have the confidence to update the tests appropriately.
Copy link
Member

@jridgewell jridgewell left a comment

Choose a reason for hiding this comment

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

Passed this time.

@nicolo-ribaudo nicolo-ribaudo added the PR: Ready to be Merged A pull request with already two approvals, but waiting for the next minor release label Oct 24, 2019
@nicolo-ribaudo nicolo-ribaudo added this to the v7.7.0 milestone Oct 25, 2019
@MicahZoltu
Copy link
Contributor Author

Is there anything I can or should do to help move this along, or is it just a matter of waiting for it to get pickup up in a release?

@jridgewell
Copy link
Member

Waiting on @nicolo-ribaudo to merge before the next appropriate release.

@nicolo-ribaudo
Copy link
Member

(Soon)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: modules outdated A closed issue/PR that is archived due to age. Recommended to make a new issue PR: New Feature 🚀 A type of pull request used for our changelog categories PR: Ready to be Merged A pull request with already two approvals, but waiting for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot load UMD module created with transform-es2015-modules-umd as an ES module.
5 participants